Designing our own software
Why does this matter?
The first that thing have to be done when creating a software is to elaborate a clear workflow that issues the main problem or task that the software will take care of. Coders have to ask themselves the right questions and by answering those questions a program workflow will arise.
In order to do that, creating a wish list of what the program is expected do is a common first step when designing new software. Also, some feedback is required from potential users for possible problems and bottlenecks identification.
Identifying the problem
The first step when designing a program is to identify the task that is required to be carried out by the program. That task adresses a specific need that no current programs satisfy in a convenient way, it may be a repetitive and rutinary series of actions that can be optimized by well thoughts lines of code or it could be very complex implementations for which there currently no implemention. Also, it is important to establish the users to whom the software will be handled, and the operating system that the users will be using. This will narrow the scope of different possibilities.
The back-bone framework
The framework could be established by answering these simple questions:
-
What do we want the program to do?
We have to write a brief and specific description of the actual tasks that the program will have to perform (i.e. printing some messages, calculating some quantities, search and classify information and so on). -
Who will be the end user of the program?
The knowleadge level of the users, the interaction frequence, and its core interest towards the solution that the program provides are quite important parameters to take into account when developing a program. This will clarify how the program should be presented to end users. -
What operative system will the end user use the program on?
Whether or not it is expected to have users simultaneously running it on Windows, Mac, and other operative systems is a crucial fact to establish the required degree of program portability. Also, it is necessary to determinate if it is possible to use standard board and mouse configuration or a more customized configuration.
Creating the Wish list
We have to depict and analyze the procedure required to perform the task more deeply. In order to do that, we should ask potential users who they currently perform the task that we are planning to optimize with our program. Useful questions are: which variables users would like to control? What is the current workflow for carrying out the task and which parts of it could be readily implemented?
More detailed information can be gathered with a survey, this might include how the users expect the program to behave? What file formats they expect to use to read the information? The more detailed the survey, the more clear the horizon to start the design journey.
Crafting a Solution
Program designing is a process where the output from one stage is the input for another, also the output from one or more stages usually should be fed back through a loop of parts of the process. There are occasions where even the process as a whole should be repeated several times. When this happens within some program code is called recursion
Understanding the problem
Once the problem has been identified, we have to be certain that we had covered all the subtleties because otherwise, we will have to return to this stage repeatedly. Some features look quite straightforward when written in natural language but require further clarification when you come to turn them into programming language.
Rising awareness about what the software needs to do
The actions that we require the program to carry are called functional requirements, examples of this actions are printing messages, sending emails, text imput by the user, or fetching some date on the internet.
Other needs or limitations are labeled as nonfunctional requirements, they are software qualities related to accessibility, usability by the end users, cost-effectiveness, compatibility with several operative systems, security, privacy, and overall performance.
In this stage it is also recommended to depict the expected result of the program execution. It might be just roughly sketched, but it will provide with useful insights about the desired results from each part of the program.
Considering maintenance
Any software that has to be executed more than one time require some sort of maintenance. Also, upgrades are a constant part of software development and a mechanism that allows seamless integration between newer and current versions should be taken into account. Furthermore, it is recommendable to write the code and the documentation in such a way that allows third parties to make contributions.
Let's add all of this into a simple example
Wish_list.txt
Problem: Get the computer to add 2 plus three and print the result.
Target users: Me
Target System: Microsoft Windows
Interface: Cmd
Functional requirements: Add two numbers, print the result, input some numeric data.
Testing: Simple run-test -expecting the result of a sum to appear.
Maintainer: https://steemit.com/@joelsegovia
To be continued on a next post of the series Self-teaching how to code with Python
Previous work
Sources:
- Learning Python, Mark Lutz. O'Reilly, 4th edition
- Python Para Todos, Raúl González Duque. (Licenced under Creative Commons Attribution ShareAlike 2.0)
- Python 3 for absolute beginners, Tim Hall and J-P Stacey. Apress
- Python for Software Design, Allen B. Downey. Cambridge University Press
