o Conhecer as necessidades do cliente

o Definir os requisitos
o Avaliar a viabilidade do projeto
o Documentar todos os procedimentos
o Escolher a metodologia de desenvolvimento
o Testar as funcionalidades criadas
Vamos ver um pouco mais sobre cada um desses pontos agora.

1. Conheça a necessidade do cliente

Todo projeto precisa ter uma reunião inicial, onde serão feitas
discussões gerais sobre o que é necessário. Isso é um passo, de certa
forma, lógico. Em outras palavras, como cada parte poderá saber o
que precisa ser feito e se tem como ser feito? Essas são dúvidas que
são sanadas na primeira reunião que acaba funcionando como uma
reunião de start do projeto.
O objetivo desta reunião é entender o que o cliente precisa, o porquê
ele sente a necessidade daquilo e o quão disposto ele está a investir
neste projeto. Esta última informação é muito importante porque é com
ela que iremos contratar pessoas, ferramentas e serviços para o
projeto especificado.

Claro que apenas uma reunião pode ser difícil para definir tudo isto,
mas a ideia é que haja um consenso geral rapidamente, para que
exista logo um ponto de início no desenvolvimento do software.

2. Defina os requisitos
 Com esta reunião serão definidos os requisitos do software a ser
criado. Estes requisitos podem ser funcionais ou não-funcionais,
dependendo de sua aplicação no projeto.
Com os requisitos em mãos, elabora-se uma lista de prioridades após
uma profunda análise de requisitos. Esta lista mostrará o que o
software precisa ter, o que pode limitar cada função e quanto tempo
aquilo poderá demorar, em teoria.
Quando existe uma definição entre cliente e empresa do que deve ser
feito, os requisitos são documentados, o que costuma ser a parte mais
complicada para desenvolvedores, mas muito importante para o
projeto em geral.

Porém, antes de documentar, é necessário avaliar se o projeto é

possível de ser realizado. Em outras palavras, viável.

3. Avaliação de viabilidade

Esta etapa do projeto é uma das mais importantes porque ela irá
impedir muito retrabalho, ou mesmo que se assumam
responsabilidades que não podem ser cumpridas de forma alguma.
Para evitar isso, é necessário ser realista e perceber o que vai ser
preciso para fazer o projeto sair do papel.

Neste passo, analisa-se:

o Pré-existência de soluções que façam o mesmo e por um

preço menor. O que, no final das contas, pode ser mais vantajoso para
o cliente;
o Pré-existência de frameworks e códigos que possam ser
reaproveitados de alguma forma;
o Número de pessoas e capacidades necessárias para a
formação de uma equipe;
o Quais tecnologias serão usadas, como o banco de dados,
serviço de cloud, linguagens de programação, etc.
Tudo isto precisa ser bem analisado, porque não podem
haver gaps quando o projeto começar. Por exemplo, se for definido
que Ruby on Rails será a tecnologia do projeto, é necessário ter, pelo
menos, desenvolvedores seniores que dominem a tecnologia.
Se for necessário contratar mais pessoas, é necessário ver o quanto
isso irá custar e se o budget do projeto permite tal ação. Tudo isto
deve ser passado ao cliente para que ele autorize ou não o start do
projeto.
Havendo a aprovação, é hora de começar a documentação.

4. Documentação!

Sabendo o que deve ser feito, é a hora de definir detalhes mais

profundos do desenvolvimento. Nessa etapa, são criadas as
documentações que listam o que será desenvolvido e como o
processo terá que acontecer. Para isso, entram em cena
os wireframes (espécie de exemplos do que deve ser feito),
fluxogramas e casos de uso, ferramentas de projetos que fazem toda
a diferença na documentação.
Por mais que a documentação do projeto seja algo que desenvolvedor
não gosta de fazer, é uma etapa essencial para o bom andamento do
projeto, pois é onde o time irá se basear na hora de desenvolver o
software. Se der algum problema, é na documentação que
encontraremos a maioria das respostas.

A documentação é um passo que dura o projeto inteiro, mesmo

durante as alterações incrementais. Isto acontece porque tais
documentos funcionam como um manual do desenvolvedor, onde se
diz o que tem de ser feito e como.
5. Metodologia de desenvolvimento

Uma das características que é escolhida quando o projeto está sendo

planejado é qual será a metodologia de desenvolvimento. Atualmente
as metodologias ágeis tendem a ser as mais escolhidas, mas isso
depende do projeto e das partes interessadas.

Esta é uma decisão muito importante pois ela direcionará a forma

como o projeto será desenvolvido, as pessoas que farão parte,
quando e quais entregas serão feitas, além de outros detalhes
importantes.

Com tudo isto definido, o projeto já poderá ser iniciado! E depois, o

que deve ser feito?

6. Testes e mais testes

Na hora em que as primeiras funcionalidades já estiverem prontas

(levando em consideração um projeto Scrum), elas deverão ser
testadas e entregues. Os testes devem ser muito bem documentados
e realizados, buscando emular o uso real da aplicação.

É necessário se colocar no lugar do cliente, como se fosse realmente

ele utilizando a funcionalidade que foi criada. Este costuma ser um
dos principais problemas no desenvolvimento de software,
principalmente, quando o teste é realizado somente
pelo desenvolvedor, que muitas vezes não possui o conhecimento
necessário para realizar o teste com a mesma eficiência que um
testador especialista faria.

IMPORTANTE: devido a esse contexto apresentado, cada vez mais

os desenvolvedores estão precisando tornar-se especialistas em
Testes de Software e o mesmo está acontecendo com os testadores
que, por sua vez, estão tendo que aprender sobre desenvolvimento e
programação. Portanto, se você pretende ingressar em alguma
dessas áreas, tenha isso em mente. Isso pode ser um diferencial
enorme!
Uma das principais dicas que podem ser usadas para evitar
problemas relacionados a bugs e a péssima experiência de usuário, é
basear o desenvolvimento da aplicação nos princípios de usabilidade
de Nielsen, que são referência internacional no processo de
desenvolvimento e da experiência de usuário (UX).

Agora que você já sabe como um projeto de software pode ser criado,
que tal descobrir mais algumas dicas gerais?

(Bônus) Avalie os riscos

Para evitar qualquer tipo de problema, deve haver um planejamento

que consiga proteger o seu projeto. Para isso, inúmeras medidas
podem ser tomadas. A primeira seria a utilização de backups, um
importante recurso para qualquer projeto digital.
Ter cópias de segurança é uma regra que deve ser respeitada
SEMPRE. Mas de nada adianta ter uma cópia do código salva se você
não a atualiza de tempos em tempos. Devido a isto, crie uma rotina
constante de backups para que nada do que foi feito seja perdido.

Além disso, é necessário ter uma infraestrutura que permita uma

rápida recuperação caso ocorra algum desastre. Não só backups, mas
ter uma equipe de suporte sempre pronta é algo muito importante para
projetos de software, pois isso pode evitar que hajam perdas de
informação e trabalho, caso algum imprevisto ocorra.

Concluindo…
Como podemos ver, não é apenas pegar um caderno e começar a
escrever o que precisamos e pronto! Surge um software. Não, é
necessário levantar requisitos, documentar todo o processo, testar e
manter este ciclo enquanto for necessário. Mais do que querer, é
necessário saber o que pode ser feito.

Se você precisar de uma metodologia que ajude neste processo,

indicamos que você conheça o Scrum mais de perto. Este framework
é excelente e vai ajudar você a guiar o processo de desenvolvimento
de uma maneira funcional e com entregas rápidas.

Claro, o cenário acima é pensando em um projeto profissional, onde

diversas pessoas, tecnologias e metodologias estão envolvidas (o
melhor dos cenários). Você deve ter reparado que, ao longo do texto,
citei diversos cargos, nomes de tecnologias e métodos, certo? Pois é!
É bastante coisa, mas não se desespere com isso. Se você está
começando, não tem grana para contratar uma equipe de
funcionários, mas quer se aventurar e criar seus próprios projetos. Vá
em frente! Comece com projetos menores onde você irá conseguir
desempenhar todos os papeis e garantir a qualidade final do software.

Banco de Dados Farmácia

Nome: Alessandra Silva
Matéria: Analise e Projeto de Sistemas
O Sistema
O sistema se baseia no gerenciamento dos registros de mercadorias da drogaria e atende às
necessidades básicas de controle de estoque, funcionários, vendas e convênios. O sistema é
utilizado pelo gerente da loja, responsável por cadastrar as informações referentes aos
funcionários, departamentos e convênios, que, com a ajuda dos farmacêuticos e auxiliar de
farmácia, gerencia o cadastro dos produtos e controla entradas e saída do estoque.
Requisitos Funcionais:
- [RF1] Cadastrar, excluir e alterar produtos: O sistema deverá permitir cadastrar novos
produtos com todos os seus atributos. O cadastro não poderá ser realizado no caso de já existir
no sistema um produto com o mesmo código. O sistema deverá permitir a exclusão de
produtos por nome ou código. O sistema deverá atualizando a os atributos dos produtos e caso
estes produtos estejam em pedidos, esses pedidos deverão ser atualizados também.
- [RF2] Cadastrar, excluir e alterar clientes e fornecedores: O sistema deverá permitir cadastrar
novos cliente ou fornecedores com todos os seus atributos. O cadastro não poderá ser
realizado no caso de já existir no sistema um cliente ou fornecedor com o mesmo código. O
sistema deverá permitir a exclusão de clientes ou fornecedores por nome ou código. O sistema
deverá atualizando a os atributos dos clientes ou fornecedores e caso estes estejam em
pedidos ou em documentos de cotas a receber ou a pagar, esses documentos deverão ser
atualizados também.
- [RF3] Cadastrar venda: O sistema permitirá cadastrar vendas dos produtos.
- [RF4] Cadastro de condições de pagamentos. Para que a empresa passa a controlar melhor o
número de parcelas que o cliente poderá pagar.
- [RF5] Cadastro e controle usuário para manter a segurança da informação;
- [RF6] Cadastro e controle do estoque, para que a empresa possa rastrear seu estoque. O
sistema deverá permitir a alteração do estoque nunca a exclusão dos registros de lançamentos.
-[RF7] Controle e análise financeira dos clientes através de consultas dos documentos
financeiros;
- [RF8] Emissão de relatórios financeiros e de cadastro.
Requisitos Não Funcionais:
- [RNF1] Será criado um documento contendo um diagrama de classes, diagrama de caso de
uso com suas descrições e com os demais diagramas, como também informações sobre o
código fonte.
- [RNF2] Será criado um cronograma detalhado para o processo de desenvolvimento no qual
constem: as atividades a serem desenvolvidas e em que período e com que recursos humanos
e físicos serão desenvolvidos o sistema.
- [RNF3] A interface do sistema será agradável, objetiva e trivial ao usuário. Suas
funcionalidades e informações deveram estar bem visíveis e disponíveis.
- [RNF4] Comunicação entre o sistema e usuário será com mensagens simples, explicando o
erro gerado e evitando termos técnicos.
- [RNF5] Os relatórios no com o filtro de um mês não deverão demorar mais que 7 segundos
para serem gerados.
- [RNF6] O tempo de resposta para as operações do banco de dados deverá ser de, no
máximo, 3 segundos.
Requisitos Inversos:
- [RI1] O sistema não deve ser acessado pela internet.
- [RI2] O sistema não pode excluir registros de lançamentos.
Casos de Uso:
Diagrama de Atividade:
Diagrama de Classe:
Diagrama de Estado: