O objetivo que tinha em mente ao desenvolver essa pesquisa era solucionar o case de um colégio, de transformar o atual sistema de reservas de equipamentos de informática e vídeo em algo digital e que facilite o uso, traga agilidade e seja confiável, com base no uso das matérias do bimestre do meu curso de Análise e Desenvolvimento de Sistemas, sendo elas Economia e Mercado, Engenharia de Software II, Projeto de Interface com Usuários e Programação Orientada a Objetos I, justificando motivos e razões que fomentaram as decisões em torno do case fornecido.
Foram aplicadas na criação de um aplicativo, dinâmicas das matérias nas formas de criação de gastos teóricos para a realização do serviço, prazos de entrega, requisitos do software como qualidade e usabilidade, acessibilidade das interfaces desde fontes até treinamentos necessários.
- Mercado
Para haver em primeiro lugar um Mercado onde haja negociações, é necessário que existam agentes econômicos dispostos a realizar trocas e transações. Podemos considerar que agentes econômicos são aqueles que criam uma determinada demanda de serviço ou produto, aqueles que ofertam produtos ou serviços ou mesmo entidades que realizem a regulamentação de algum desses processos.
Existem 3 principais agentes econômicos citados na teoria econômica que são as Famílias, Empresas e o Governo. Famílias são unidades consumidoras e também podem ser detentoras de fatores de produção (como terrenos e o trabalho, e em nosso projeto, o colégio); Empresas são as que produzem serviços e bens, e para isso usam os fatores de produção acima citados (terrenos, mão de obra); Temos também o Governo atuando na tentativa de diminuir desigualdades econômicas e na manutenção e eficiência do sistema econômico como um todo.
Definimos então que os agentes econômicos em nosso projeto serão nossa empresa de Desenvolvimento de Software como uma Empresa oferecendo um produto e o colégio composto por unidades de Família que necessitam deste produto.
- Viabilidade Econômica
A necessidade do estudo da viabilidade econômica origina-se do intuito de projetar o retorno financeiro do mesmo, se haverá prejuízo ou lucro e no caso de possível lucro, quantificar o tempo necessário para tal.
É importante salientar que, como citado por Machado (2016) a microeconomia buscará o equilíbrio entre o mercado de bens e serviços na formação de preços entre oferta e demanda, buscando um meio termo entre acessibilidade de valores para quem compra, contrata e maximiza a renda de quem oferece.
O primeiro passo então é calcularmos qual será o custo de desenvolvimento desse software, quanto tempo levará para termos ele usável, quais imprevistos podem surgir durante seu desenvolvimento bem como riscos (por exemplo um funcionário abandonar o projeto, desistência ou quebra de contrato por parte da contratante, etc).
Um exemplo rápido, quem sabe meio raso: nosso custo por hora para dois desenvolvedores seria R$ 52,80, e com um prazo de 20 dias úteis teríamos um gasto de R$ 9.292,00 no desenvolvimento desse app, e projetando para somente o sistema do Colégio ao menos 40 horas de manutenção ao mês, o gasto mensal seria R$ 5.640,00 (Administrativo, impostos e as 40 horas de manutenção do software).
Com dois desenvolvedores dedicados a criar esse sistema do zero, e devido a sua complexidade razoavelmente baixa, podemos definir como prazo de entrega dois meses mais aproximadamente sete dias para realizar testes com ela já implementada.
- Engenharia de Software: Qualidade
Antes de se iniciar o desenvolvimento de um software, é interessante, até mesmo essencial, ter em mãos informações que garantem que o projeto do software irá atender exatamente o que é esperado. Para isso existem normas tanto nacionais quanto internacionais que norteiam a direção para existir uma mínima qualidade na entrega e manutenção de software.
Podemos listar algumas como a - ISO/IEC 9126 que foca na qualidade do software e propõe seis (6) atributos, sendo elas: Funcionalidade; Confiabilidade; Usabilidade; Eficiência; Manutenibilidade e Portabilidade. Incluem subcaracterísticas dentro de cada desses atributos, a norma ISO/IEC 9126 permite visualizar o que seria necessário para definir essa qualidade empregada.
A ISO/IEC 12207 que estabelece uma estrutura comum para os ciclos de desenvolvimento de software, essa estrutura consiste em processos modulares que são categorizados pelo seu objetivo no dito ciclo, sendo quatro (4) categorias, em resumo: Processos Fundamentais (envolvem aquisição, fornecimento e desenvolvimento); Processos de Apoio (envolvem documentação, configurações, validações e auditoria); Processos Organizacionais (envolvem a gerência, infraestrutura e recursos humanos) e Processos de Adaptação (que envolvem atividades básicas como linguagem usada e organização).
Além de outras normas ISO como ISO 10011 (que trata do processo de auditoria para sistemas), IEEE P1061(Metodologia de métricas para produtos de software) e também um modelo chamado CMM que apesar de não ser uma norma ISO, é uma avaliação de qualidade do processo de desenvolvimento de software muito bem aceita no mercado.
CMM que significa em português Modelo de Maturidade em Capacitação, é resumido como um complicado das melhores práticas de desenvolvimento presentes em outras normas e avaliações. O mesmo trata os níveis de maturidade em uma escala de 5 (cinco) itens, sendo o Nível 1 ou Inicial, e na sequência os níveis Repetíveis, Definidos, Gerenciados Quantitativamente e Em Otimização.
Quero pontuar também algo escrito na própria guideline do CMM, página 14, seção 1.6
“...Sound judgment is necessary to use the CMM correctly and with insight. Intelligence, experience and knowledge must shape an appropriate interpretation of the CMM in a specific environment. That interpretation should be based on the business needs and objectives of the organization and the projects. A rote, checklist-oriented application of the CMM has the potential to harm an organization rather than help it…”
Em tradução resumida, o bom senso é necessário para se usar o CMM, e a aplicação passo a passo do CMM pode ser mais prejudicial a uma empresa do que o contrário.
Para basear a criação da nossa empresa fictícia de desenvolvimento de software, usaremos então com bom senso as orientações do CMM como norte. Sendo assim, podemos concluir que iniciaremos como Nível de Maturidade um (1), com as práticas de desenvolvimento do software em si alcançando o nível dois (2), pois estaremos já demonstrando o básico em gerenciamento de custos e da qualidade do software entregue.
- Requisitos
Requisitos funcionais e não funcionais de um software, de forma simplificada são uma descrição do que o mesmo deve realizar para atender a necessidade do negócio ou cliente.
Também atualmente são utilizados conceitos diferentes de requisitos para definir os objetivos de um sistema, conceitos como OKRs (Objectives and Key Results), método que ficou famoso por ter apoiado o crescimento do Google e que foi criado pelo ex-CEO da Intel, onde os objetivos são qualitativos, e os resultados quantitativos; BDD (Behavior Driven Development) que é uma técnica para desenvolver software de maneira ágil baseada na integração de regras de negócio com a linguagem de programação, focando os testes no comportamento do software e alinhando a comunicação entre time e cliente final; Bem como conceitos de “Produto” e Métricas para Produto e “User History”.
É importante utilizarmos os requisitos demonstrados em Engenharia de Software II para montar uma base do necessário em nosso sistema de Gerenciamento de Estoque Tecnológico para o Colégio, e coletarmos feedbacks dos nossos usuários para poder ter uma melhora constante desse app.
Já os requisitos não Funcionais funcionam como uma parte do escopo do nosso produto, sendo qualidades ou restrições específicas a nossa implementação, necessários para expressar a qualidade dentro do contexto do case. Podemos categorizar os requisitos não funcionais em partes, como Requisitos do Produto, Requisitos Organizacionais e até Requisitos Internos. Um exemplo claro e moderno é de um software que lida com informações sensíveis, a fim de atender os requerimentos da LGPD.
- Regra de Negócio
Em 1989 a IBM anunciou um sistema para gerir o desenvolvimento de software chamado de AD/Cycle para sua SSA (Systems Application Architecture), sendo definido como “um requisito sobre as condições ou manipulações de dados expressos em termos de empresa comercial ou domínio de aplicação" criando o conceito de regra de negócio onde é necessário um agente e uma condição. Regras de Negócio são um conjunto de operações condicionais ligadas a um resultado de dados; e dados são a essência dos sistemas de informação empresariais.
Juntamente aos Requisitos Funcionais e Não Funcionais, as Regras de Negócio constroem o conceito de Requisitos de Software, aliando o necessário aos usuários para que trabalhem na ferramenta, com premissas do desenvolvimento de software e critérios do próprio negócio que precisam ser atendidos.
Algumas das regras de negócio do nosso case envolvem o gerenciamento de material tecnológico do colégio, hoje o gerenciamento é realizado de maneira manual, levando tempo e mais suscetível a erros. As regras que já temos para essa organização são garantir que os equipamentos e salas que são reservados pelos professores estejam corretamente organizadas no dia para impedir que mais de um equipamento ou sala seja reservada no mesmo horário por professores diferentes, por exemplo.
Vamos então classificar nossas necessidades e caminhos que o software irá percorrer para permitir a reserva de uma sala ou equipamento, bem como seus avisos de confirmação e erro.
- Interface do app
Segundo Rocha e Baranauskas (2003) o conceito da Interface ser responsável apenas pela comunicação com o usuário, hardware e software evoluiu e devemos hoje levar em consideração mais aspectos humanos durante essa comunicação, logo, Interação e Interface são duas coisas que caminham juntas para criar o melhor ambiente possível.
Para criar nossa Interação, levamos em consideração muitos aspectos da usabilidade, principalmente as definidas pelas NBR ISO/IEC 9126-1 onde usabilidade é a “capacidade do software de ser compreendido, aprendido, operado e atraente ao usuário, quando usado sob condições específicas" (ABNT, 2003, p. 7).
A começar pela tela de Login, com espaços claros para inserir nome de usuário e senha, bem como requisitar acesso em algum caso específico do Professor ainda não ter sido incluído, e a opção de Redefinir a senha em caso de esquecimento.
O foco do menu principal é ter uma produtividade veloz na hora de realizar a reserva do equipamento ou sala necessária, sendo essas opções as primeiras disponíveis na aplicação, o que garante também uma curva de aprendizagem muito baixa, afinal segundo (FERRÉ et al., 2001) os usuários não podem gastar muito tempo aprendendo como os sistemas trabalham, além de escolhas mais óbvias como garantir um menu em português e botões de tamanho médio pra grande.
- Entrada de Dados, Processamento e Saídas
Para o funcionamento fluido do nosso aplicativo, bem como de qualquer sistema, é necessário que sejam fornecidas informações a ele. Todo algoritmo vai precisar de um "input", seja ele um sensor, um botão, um campo para escrever e a partir disso as operações e cálculos serão realizados.
O conceito mais básico de programação e sistemas é o modelo IPO, que significa Input-Process-Output, funcionando como exemplos do mundo real como o Sistema Respiratório, onde é feito o “Input” de Oxigênio, a Hematose pode ser considerada o “process”, onde é realizada as operações com o oxigênio garantindo a oxigenação das células, e o “output” sendo o gás carbônico antes presente no sangue sendo expirado.
O mesmo acontece em diversas fases do aplicativo, na tela de Login é necessário que o usuário preencha as informações de conta e senha, onde o sistema irá verificar se a conta e senha batem com informações já armazenadas, então mostrando uma saída de informação booleana baseada nisso: se as informações estão corretas, o usuário é levado ao menu principal, e se não estiverem corretas, uma mensagem de erro é exibida na tela.
Tela de Reservas - Usuário escolhe as opções disponíveis da lista fornecida, apenas clicando sobre a mesma (input), o processamento é realizado por nosso código e as informações são salvas numa base de dados SQL, usando.
Tela de Horários - Usuário determina o horário inicial da sua reserva com data e hora, por padrão o sistema assume o uso por duas horas mas o usuário pode selecionar mais horas de uso. Ao clicar em “Salvar Horários" as informações são enviadas a base de dados SQL e a mensagem com “Reserva Confirmada!” seguida da data e horários selecionados aparece na tela, acompanhadas de duas opções: Voltar ao Menu Inicial ou checar o Calendário.
Tela de Salas - Mostra todas as salas disponíveis de ambos os Prédios 1 e 2, nomeando cada sala, mostrando qual está sob reserva do usuário logado, o mesmo pode alterar a sala (input) e salvar sua sala com horário inicial informado também podendo ser alterado, e as informações novamente são salvas e o output será a mensagem de confirmação de reserva informando o horário inicial e final da reserva.
A estrutura básica de entrada, processamento e saída de dados do aplicativo se manterá dessa maneira. Com a interface pensada em produtividade, eliminamos boa parte dos problemas que podem comprometer o uso pelo usuário, como necessitar de diversos treinamentos; não lembrar de funcionalidades pouco utilizadas; não aprender todas as funcionalidades; levar tempo demais para realizar a tarefa desejada.
Para concluir, fica claro a necessidade de levar em conta a organização de tempo para a entrega satisfatória, a organização financeira para que o desenvolvimento tenha lucro e seja atrativo ao investimento por parte do Colégio; Atenção aos detalhes durante a produção do mesmo para garantir com que todos os Requisitos sejam cumpridos, o principal sendo a reserva de equipamentos por parte dos professores, cuidados ao elaborar os requisitos não funcionais e de negócio, pois apesar de estarem “fora” do uso dos professores ainda assim serão parte fundamental das estratégias de desenvolvimento.
Os processos de desenvolvimento de Interface, começando por um desenho básico em lápis e papel, até ser levado a um programa próprio a isso, organizar logicamente as etapas de telas, cores e fontes que tragam bem estar ao uso do aplicativo, bem como acessibilidade em questões de daltonismo ou visão prejudicada até a parte de Linguagem de Programação, em sua escolha, definição das regras de Heranças e Classes, entendimento do paradigma proposto para que seja possível usar esses recursos da melhor maneira, tudo isso é possível de se observar durante as etapas definidas do projeto, atendendo aos pontos principais do case e entregando o aplicativo.
Principais telas do app, podem ser vista em alta resolução neste link
Referências
SILVA, Maria Valesca Damásio de C. Introdução às teorias econômicas. Salvador: UFBA, 2016.
CARDOSO, Rodrigo Pinheiro. Objectives and Key Results (OKR) Aplicado a uma empresa industrial: Um estudo de caso. Porto, Portugal: FEP, 2020.
GRADY, Jeffrey. System Engineering Planning and Enterprise Identity. Florida: CRC Press, 1995.
LEWIS, John. Java Software Solutions: Foundations of Program Design. 6 Edicao. Londres: Pearson, 2008.
Websites
CUNHA, Fernando. Requisitos funcionais e não funcionais: o que são? Mestres da Web, 2022.
GOMES, Vanessa. Métricas de Qualidade de Software. TI Especialistas, 2016.
Salários de Java Developer em Brasil. Glassdoor, 2021.
AD/CYCLE: IBM'S SAA Application Development Solution. IBM, 1990.
Cores em UI: Um Guia Rápido Para Usar em Seus Projetos. AELA, 2020.
Top comments (0)