The first knowledge we need it is to know the posibilities or methodologies that exists to create Software. Each methodology is used to develop diferent types of Software. The types usually are defined by the requeriments and the diferent normative that is related to the type of device. In the next post I will explain how to find the normative@ legislation (link), and how does it work. 

Let's start with methodologies. There are lot's of methodologies and so many people that develop new ones. I will only explain the main ones in my point of view. The chosen ones are: Cascade, Incremental, Iterative,... Before the explanation I will explain shorty the common steps separately, and then the methodologies I have chosen. In next publications I will explain the steps in detail if needed or the people asked.

STAGES

1. Requirements Definition
   

   In this step it may need to define exactly the requirements. It is very important to define them without ambiguity and they express clearly what they want. The way to define these requirements if there is no normative you could define as you want. In my opinion the requirements may answer these questions:
   - Is the system completely defined by the client? I mean we have all the functions the client want...
   - Are the Hardware interfaces defined? It means that we know how the connections works, i we use SPI, I2C, CAN, and also we know the protocol it used.
   - If we use a software library, is it defined the way we are going to use these library?
   - Are we satisfying all the normative and regulations?
   - Are defined the needs for the end user tests?
   If have answered these question i thing it is enough for now. In some cases the normative define what are the minimum requirements.

2. Analysis of Requirements 
   

   In this step It is needed to take the requirements and start the relations between them. I mean, when I analyze the requiriments, It appears new ones, that joins them with new restrictions. For example, you have a transceiver and a microcontroller, and the transceiver only could communicate with the line I2C, and in the micro-controller exists 2 lines, but only one of them could use I2C, so the new requirement is "the module 'x' of the micro-controller will use I2C, and it will use the pins 'p1.1' and 'p1.2'". 
   With the requirements that appear in this step and the first ones, you will have defined what the client want, and also you have designed parts that could not change.

3. Design of Software
   

   In this step it starts designing the software. For the design there are some tools, but you may put all the requirements into use cases, statecharts, algorithms. In other words translate the requirements into Software schemes. The best choice it is using UML.
   In my case, I'm used to design with some Software tools. The ones i could recommend are:
   - Rhapsody: This tools allows you to simulate state machines, use cases, statecharts, and also if you have designed correctly the class diagram you will get the main skeleton of the source code.
   - Enterprise Architect: These tool it hasn't got simulation, but you could design more accurate the program, and also you could store the requirements and it has traceability between the requirements, the test, the units of software. I recommend this tool if you have to documents all the steps (highly recommended for satisfy the normative).

4. Unit Implementation
   

   In this step, you have to implement the parts of the program to satisfy the program flow. A unit could be a variable, a function, a class, a namespace, a library, ... In other words enter the code.

5. Unit Integration
   

   In this step, you join all the unit implementation with the main frame. I think it is not needed to explain more.

6. System Test
   

   In this step the software is probed. There some strategies for doing that. In my opinion and also it is needed to satisfy normative in some cases. You need to test each requirement trying to isolate from other ones.

7. Operation and Maintenance
   

   This step it is optional in most of cases, but it is good to have in mind how you or another people could change the sources, or define how to use the sources, if it is necessary for relation with other devices, or components.

METHODOLOGIES

CASCADE

This model/methodology is also called classic, traditional or lineal. This model is the best choice if we know exactly the requirements and these requirements will not change, or they have tiny changes. You will pass all the steps only once. This model it is the fastest one, but changing a requirement could mean to start again and redo all the work. 

Pros

- When you finished you have a full version with 100% teorical functionality.

- It has completly traceability, cause ou could not begin wth one stage until you finish the previous one.

Cons

- If there are changes in any stages you may restart the develop of all the software.

- All the requirements must be define completly.

- There are not Software until the end of the project.

ITERATIVE

This model it is the same the cascade model but repeting n times the process, so you have a feedback of the end user Software and you redo the project.

Pros

- Same as cascade

- The Software is improving itself

Cons

-Same as cascade

INCREMENTAL

 This model/methodology is based in the client defined requirements, but you will not have to define them completly. In this method the Software is developing with the core and them the functionalities are being added to it. For example of this methodology it is, a word procesor. In the beginning you could design only the main funcionalities as writting text and saving into file. But you could add bol text or italics...

Pros

- The stages are defined continuosly. It means the software is improving itself when developing.

- It is close to the Cascade Model but with Feedback.

- You could have functional software, but not operative aproximately at the middle of the project.

Cons

- The main requirements must not change.

- It must have defined the traceability very goog (There are very good Softare aplications for this purpose).

SPIRAL

 It's the most professional cycle of life. The problem It's that is the most difficult to follow. This model It's related to critical Software, or Software that needs to document very clearly to apply for normative or whatever. In this model we mix the iterative model with the cascade. The main difference with the incremental it's that the stages change a little bit. In this one you may go through 6 diferents stages. I will only put here, if the people it is interested in it I will explain in another post. The 6 stages are: Communication with the client; Planning; Risk Analysis; Engineer Study; Implementation; and Feedback. Also i need to comment that you have a iteration roughly each of the defined stages in this blog.

Pros

- The most professional

- Very easy to obtain the documentation

- Ordered

Cons 

- Very difficult to follow without experience

- Hard to administrate & control

P.D.: If someone need more information, I will answer all the question, please comment and I will answer as soon as possible. And please, forgive my English mistakes...