Planning for application program

Thread Starter

Sparsh45

Joined Dec 6, 2021
143
What I don't understand is how planning is done to develop application programs that runs on the operating system. Obviously my question is related to the microcontroller on which the operating system runs. Right now I can't tell about the specific operating system it can be any which is running on the microcontroller.

I have heard that people who develop application programs for operating systems. Use paper and pencil before writing code, do they design state diagrams on paper? I do not know how many people develop application programs here, maybe someone does, then please tell your strategy
 

MrChips

Joined Oct 2, 2009
27,670
What I don't understand is how planning is done to develop application programs that runs on the operating system. Obviously my question is related to the microcontroller on which the operating system runs. Right now I can't tell about the specific operating system it can be any which is running on the microcontroller.

I have heard that people who develop application programs for operating systems. Use paper and pencil before writing code, do they design state diagrams on paper? I do not know how many people develop application programs here, maybe someone does, then please tell your strategy
This is done everyday by application developers.
Writing code is far down on the list of tasks to be performed.
If you are designing an application program or any type of commercial product, your first steps ought to be:

1) What is the function of the product?
2) Is there a market for the product?
3) Has a survey of the market been conducted?
4) What is the perception by the market of your product?
5) What is competition to your product?
6) What does the cost/price analysis of the product reveal?
7) What are the risk factors in developing/manufacturing/maintaining the product?

Next steps into the product development:
1) Write the user manual for the product.
2) Produce mock-up and conceptual design of the product.
3) Produce a simulation of the product.
4) Have the design and user interface tested by persons outside of the development team and by potential clients.

And we have not even started looking at code design!
By this stage you would have the functional specifications of the product well defined.
 

KeithWalker

Joined Jul 10, 2017
2,609
As Mr. Chips stated, first the application must be well defined. Once a full functional specification has been produced and decisions have been made on what platform, language, firmware and interfaces will be used, the design of the software can begin. There are many different graphic tools available to make this task a little simpler. Basically, the application is divided up into several large functional sections such as; operator interface, data collection, data manipulation and output. These are drawn up on the top sheet of the planner. On the second level down, each functional sections is divided into smaller interrelated tasks. The next level down, divides these tasks into smaller related tasks, and so-on until each task is reduced to functions that can no longer be divided. This is called Top-Down design.
The actual implementation of the software is done from the Bottom-Up. Each individual low level task is written and tested to ensure that is does exactly what it is supposed to. Then, on the next level up, the low level tasks are tested together to ensure that they interact correctly. This is repeated until the top level of the design has been tested. This is called Bottom-Up software development, and you can see that if the job is a very big one, and has been designed correctly, low level tasks can be tackled by a whole team of software specialists, each writing their own assigned function. It is the task of the project manager to ensure that each module performs and interacts correctly with all the other modules..
 

BobTPH

Joined Jun 5, 2013
6,073
Edited ti add: I wrote this drawing from my experience with highly innovative projects. Every application is different, and requires different approaches, I am presenting one of these. The lovely wife Morticia worked in more traditional applications, and she pointed out that in her field, the user manual was the specification, it was all about user interaction.

With all due respect, I think the posts by MrChips and KeithWalker reflect corporate propaganda and are nonsense. I worked in the software industry for over 40 years and rarely saw a successful project follow the structured approach they present, while I saw many failures of such projects.

The successful projects I have worked on were usually the result if a single person or small group, often hiding their efforts from management. There was nothing like a spec, let alone a user manual before coding started.

Exploratory code was written without consideration of user interface details or complete functionality. This code was modifed rapidly, with large pieces scrapped when the did not work out, and the functional details worked out by trial and error.

When a successful prototype was done, then it was presented to management and a more traditional process put in place. Much of the code was rewritten with the knowledge gained from the prototype.

The most commercially successful project I worked on my in my career produced $100M in sales in the first year, because we solved a problem for a customer we were unable to win without this innovation.

It was proposed as an idea that could be expressed in a single sentence by a very talented consulting engineer. He came to me with the question of whether it was possible, because it involved my area if expertise. After an initial feeling of no, I found that all of my gut feeling objections turned out to be wrong, and it was quite doable.

I worked in a prototype without telling my management what I was doing. Once the prototype was done, we brought it to the customer (management was informed before that.). In two weeks we brought up their million-line application on our company’s hardware, which they had considered impossible before.

After that, the project was given to another team who made it a product.

Bob
 
Last edited:

MrChips

Joined Oct 2, 2009
27,670
The successful projects I have worked on were usually the result if a single person or small group, often hiding their efforts from management. There was nothing like a spec, let alone a user manual before coding started.

Exploratory code was written without consideration of user interface details or complete functionality. This code was modified rapidly, with large pieces scrapped when they did not work out, and the functional details worked out by trial and error.

When a successful prototype was done, then it was presented to management and a more traditional process put in place. Much of the code was rewritten with the knowledge gained from the prototype.

After that, the project was given to another team who made it a product.


Bob
With all due respect, you created a prototype and demonstrated proof of concept albeit by trial and error. You had unknowingly created the user manual and laid out the specifications of the product. The prototype was alpha tested by the client. The final development was actually performed by another team based on your prototype.

One of the objectives of laying out the specifications in detail is to avoid returning to the drawing board and having to do a major rework.

This actually fits in perfectly with the scheme I had already presented.
 

MrChips

Joined Oct 2, 2009
27,670
The TS is asking about how an application program development proceeds. I have stated that code writing does not begin until the groundwork has been laid, i.e. the functionality, user interface and specifications are fully developed and presented. With this covered the actual software team has well defined specifications to follow.

@KeithWalker explains the concepts of Top-Down Design and Bottom-Up Implementation very well. Both top-down and bottom-up coding can proceed in parallel.

I am an Apple Developer and created CAD applications for Apple Macintosh when it first came out. My main program was laid out like this:
Code:
Initialize
REPEAT
   GetNextEvent
   DoEvent
UNTIL done
The beauty with this is that the program is running from day one. The details of each function can be implemented as work progresses. This is Top-Down implementation with a clear road map.
 

KeithWalker

Joined Jul 10, 2017
2,609
In the many years I worked for Hewlett Packard as a project engineer and consultant, I developed many software driven automated hardware systems for customers. Each one used the methods I described and each one was completed and signed off to the customer on time, within the quoted budget and with customer satisfaction.
During that time I also worked on renovating a number of older systems with software that had been constructed in the way BobTPH described. We called it "spaghetti coding" because it had just "grown" without any structure. Because of that, if a small change was made to correct a problem in one place, it caused all kinds of unexpected things to happen in other parts of the program. It was a nightmare to support and in most cases, it was more economical to just re-write it.
One of the most important features of top-down development with bottom-up implementation is that it is modular. Each module is well defined and self-contained and independent of the other modules. A module can be modified or replaced without it causing unexpected results in other places. That makes for robust, supportable software.
 

BobTPH

Joined Jun 5, 2013
6,073
During that time I also worked on renovating a number of older systems with software that had been constructed in the way BobTPH described. We called it "spaghetti coding" because it had just "grown" without any structure.
You are mis-characterizing what I said. I did not describe growing a product without structure. I described very loose and free approach to getting to a prototype, followed by designing the final product with the learnings from the prototyping phase.

Spaghetti code results when an existing product is updated to learn new tricks that the original designer ls did not foresee. These eventually must be rewritten from scratch.

I think we are talking about different activities. I am talking more about innovation than product development.

It is not clear whether either of these were what the TS was asking.

Bob
 

Thread Starter

Sparsh45

Joined Dec 6, 2021
143
It is not clear whether either of these were what the TS was asking.
Have you written any embedded programs that run on the operating system? If you write such program then I can ask further questions. Generally I divide programming into two categories, first bare metal programming where we write code directly for microcontroller and second Embedded OS programming where we write application programs that run on operating system and OS running on microcontroller/Processor.

I don't have much difficulty in designing code for bare metal style I can design it with little effort. My brain doesn't understand at all how to do planning while writing code for an application program that would run on operating system.

In my views, I understood that in order to develop an application program, it is very important to know about the task, the task states, time and task order.

Many people say that if you have learned to develop application program for operating system that makes your life easier but for me it is more difficult because I don't really understand how they makes plan.
 

KeithWalker

Joined Jul 10, 2017
2,609
Have you written any embedded programs that run on the operating system? If you write such program then I can ask further questions. Generally I divide programming into two categories, first bare metal programming where we write code directly for microcontroller and second Embedded OS programming where we write application programs that run on operating system and OS running on microcontroller/Processor.

I don't have much difficulty in designing code for bare metal style I can design it with little effort. My brain doesn't understand at all how to do planning while writing code for an application program that would run on operating system.

In my views, I understood that in order to develop an application program, it is very important to know about the task, the task states, time and task order.

Many people say that if you have learned to develop application program for operating system that makes your life easier but for me it is more difficult because I don't really understand how they makes plan.
Since the early 1980s I have written programs that run on 4-bit microprocessers, DOS, Windows 98, 2000, XP etc, basic stamp, PIC, Arduino and just about anything else that would run a program, using many different languages and assemblers.
There is very little difference in planning and writing an application program whether it will on the bare microcontroller or in an operating system on the controller. The only difference is in the choice of tools available for the task.
Either way, a functional specification is absolutely necessary because that is the definition of what the application will do. It will define input and output parameters and function and will include program sequence and flow.
Once the task has been defined, the choice is made on which tools to use to write the program. This can be anything from a single pass assembler to a full object oriented high level language.
The software can then be designed using whatever design tools you prefer, bearing in mind the characteristics and limitations of the platform that you have chosen.
Writing and testing the software are the very last steps in the process.
 
Last edited:

BobTPH

Joined Jun 5, 2013
6,073
Agreed, the planning has nothing to do with whether it is bare metal or running on an OS.

I think perhaps your use of language is confusing us. What do you mean by "planning for application program". Specifically, what "planning" do you do when writing your bare metal applications?\

Also, you keep getting hung up on task execution. I spent my whole life writing programs that run on an operating system. Most were a single task, a few were multi-task. But in no case did I ever plan out how the tasks run. That is the purview of the OS. The application programmer plans any necessary cooperation and communication between tasks, not how they are run.

Bob
 

MrChips

Joined Oct 2, 2009
27,670
Have you written any embedded programs that run on the operating system? If you write such program then I can ask further questions. Generally I divide programming into two categories, first bare metal programming where we write code directly for microcontroller and second Embedded OS programming where we write application programs that run on operating system and OS running on microcontroller/Processor.

I don't have much difficulty in designing code for bare metal style I can design it with little effort. My brain doesn't understand at all how to do planning while writing code for an application program that would run on operating system.

In my views, I understood that in order to develop an application program, it is very important to know about the task, the task states, time and task order.

Many people say that if you have learned to develop application program for operating system that makes your life easier but for me it is more difficult because I don't really understand how they makes plan.
What is your definition of an Operating System?

As others have said, an OS is a set of software tools and libraries to perform various functions so that the SW developer does not have to create themselves. OS defines a set of SW layers on top of which the application is laid.
 

Thread Starter

Sparsh45

Joined Dec 6, 2021
143
What do you mean by "planning for application program". Specifically, what "planning" do you do when writing your bare metal applications?
Bob
If I'm working on a complex project I design a state machine or flowchart on the paper before I write the code. I call this process planning.
 

KeithWalker

Joined Jul 10, 2017
2,609
If I'm working on a complex project I design a state machine or flowchart on the paper before I write the code. I call this process planning.
That is only a small part of process planning. It is designing the functional specification of the project. Once that has been done, the software design and choice of platform, peripherals and tools begins.
 

rpiloverbd

Joined Dec 21, 2021
27
Everyone has said enough already. Long story short, they think about the product's features first, then work on circuits and codes etc. Then after the initial prototyping, they decide to add more features. This cycle continues until the management finally gives the green signal for product release.
 
Top