-3

I have an application that manage absence of students.

I asked everyone who will use the application (teachers , administration ...) about their needs and feature they want to see in the application.

Now I don't know what steps I should follow before creating the software?

  • should I draw a sequence diagram & use case diagram to explain to my teacher the application's feature & how it work?
  • should I start create a database for the application then begin creating the application? (it will be web with Java EE)

closed as too broad by Jörg W Mittag, amon, gnat, Bart van Ingen Schenau, whatsisname Jun 4 '17 at 4:29

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

3

I asked everyone who will use the application (teachers , administration ...) about their needs and feature they want to see in the application.

We call that requirements gathering. It's good but don't be surprised when these change.

should I draw a sequence diagram & use case diagram to explain to my teacher the application's feature & how it work?

We call this design. You can do it this way. Also worth considering is quickly mocking up GUI's with paint programs or paper and pencil. I tend to do this before getting all formal. You can add pictures, scissors and tape. The more you can show people the more they get a feel for the idea and can bring up issues sooner rather than later. Keep doing this until the changes settle down.

should I start create a database for the application then begin creating the application? (it will be web with Java EE)

There are those who let the database be the center of their application. I'm not one of them. I like to keep my business rules and entities at the center. To me the database is just another outside thing I communicate with.

What you need to figure out either way is what your model is going to be. This is how your code reflects what's going on in the real world. With a solid model it's easy to add the rest.

As Laiv rightly points out it's best to do these steps separately. Don't be thinking about how hard it will be to implement when drawing the GUI. Think about what the user needs.

Now just because you do them separately doesn't mean you have to do them days apart. The agile way to work is to push through them all while focused on the smallest thing you can think to delver. Show that to users rapidly and get feedback before you add another feature. Do this and your design won't just be a stab in the dark. You'll be feeling your way to a better design.

  • 3
    Agreed. Just a little consideration. During the requirements gathering, don't think in design nor model. Later when designing, don't think in implentation details. And so on. Do one job at a time. Mixing the jobs can distract you from the specific task you are focused on at the moment. Like my teacher used to say: when I design, I wear the designer hat. When I develop, I wear the developer hat. I never ever wear two hats at a time. It would make feel ridiculous. – Laiv Jun 3 '17 at 15:17

Not the answer you're looking for? Browse other questions tagged or ask your own question.