One of the most difficult tasks in software development is to put all the pieces together, because sometimes you aren’t working alone, and each programmer has a different style of programming. Thus, it could be a problem if you don’t know what to do with all the parts of the software.
So there’s why know we have a lot of methodologies to work with examples like, Agile, Jira, Scrum etc… So let me share this video about agile.
Until this moment the problem is solved, and the solution is implemented in code. Before continuing remember the principles of OOA
- The software does what the customer wants it to do.
- The principles of OO are well applied.
- Strive for a maintainable and reusable design.
Let’s review the process to build good software.
First you need to understand what the software is supposed to do. (Use cases diagrams are a good option here).
Be sure that you include all the system is going to need to work correctly in the use cases. The nouns are the classes and the verbs the methods. Avoid the features that doesn’t have a close impact to the solution (include only the features that are needed or that one’s specified in the requirements).
Then break up he problem into smaller pieces. Once you have the use cases diagrams this is going to be easy. Because that is one of the purposes of the use cases.
Before continuing in the process be sure that the team understand the problem and its components.
Now is time to get the requirements of the system, modify the use cases and the requirements list as you need. Is important in this step to gather the correct requirements, the code is not done yet and is better to add or remove things at this time. Making a good analysis and design is one way to know that your requirements are well covered.
Before starting to implement the solution of the design think about possible situations that you aren’t including now, this will make easy the work then.
At this point is time to start to implement the solution by coding and coding. Remember all the principles to assure flexibility in the code.
Finally, is the testing part and before this part I am almost sure that a problem come, if not congratulations you learned very well the concepts. If something goes wrong with the system you should get back to the requirements step and change the things that need to be changed. And continue with the cycle. If another problem is presented repeat the process until the system work well.
- Brett D. McLaughlin, Gary Pollice, and David West. (2007). Head First Object-Oriented Analysis and Design. United States of America: O’Reilly Media.