What is Software Engineering?

Software Engineering is the systematic aproach to the development, operation and

maintenance of software. Software Engineering is concerned with development and
maintenance of software products.

The primary goal of software engineering is to provide the quality of software with low
cost. Software Engineering involves project planning, project management, systematic
analysis, design, validations and maintenance activities.

=The content of the field=

''Note: the following summaries are originally from Wikipedia. These are here only
temporarily. The titles aren't final, nothing on this page is final yet(or even near final).''

==Vision and Scope==

The practice of software engineering in the corporate or industrial sector, starts with the
business and ends with the business. Although computers, programming languages, and
creative problem solving are what fill the engineer with interest in the field, without
servicing and enabling the user, the exercise would be pointless. Thus the first stage in
any software engineering process, is the [[Vision and Scope]] document, or some
equivalent meeting.

A vision of the system to be built is described by the user or [[Product Champion]]. The
business context that it will service is described. The key stakeholders are enumerated
including their interests, risks, etc. The success conditions are listed, so that it is
understood what will be completed and how to measure success.

Business opportunities are discussed, to justify why the project should be invested with
the blood, sweat, and tears of programmers, testers, project managers, and program
managers. The Scope of the project is made clear and if it is to be in phases, the scope of
each phase at a high level is laid out. The priorities of the project are recorded.

With an understanding of the business' vision, the engineers begin to ask questions.

==Requirements Analysis==
Extracting requirements of a desired software product is the first task in creating it. This
process is called requirements elicitation. While customers probably believe they know
what the software should do, it may require skill and experience in software engineering
to recognize incomplete, ambiguous or contradictory requirements.

Compounding this problem is the absence of formal abstractions. A civil, mechanical

engineer has a plan, elevation, sections to refer to and these make good sense to both the
author and reader of these abstractions. However, while (E-R) or object diagrams,
process flow diagrams, data flow diagrams are abstractions that have been used and built
on, many of these are not universally used or practiced.
Besides, considerable effort goes into repairing and enhancing existing systems.
Engineering required here is a mix of reverse and forward engineering in the sense that
requiremnts definitions refer to a set of circumstances that already exist and these
circumstances have to be stated in unambiguous terms as well.

Perhaps, lack of universally accepted abstractions make life difficult for software
engineers and some people have even argued that software production process is closer to
art rather than engineering!

Of late, people have started using prototypes in various degrees of working. Screen shots
and report layouts are non working prototypes and form the basic level of prototyping
and increasing sophistication is built in wherever possible. Making prototypes is always
more time consuming than not making one. Thus, this practice is not always utilised.

===Analyst Role===
The role of analyst can be fulfilled typically by three types of people. A technical project
manager, a software engineer, or a dedicated analyst. In some organizations it is
unthinkable to engineers that they would serve the analyst role, as they are "technical"
and would consider dealing directly with the customer unthinkable. This is purely a
cultural stance that varies between companies and organizations. It is also quite common
for software engineers to work closely with the business people and customers associated
with a project, and this programmer/analyst role can be quite beneficial to the projects
success rate.

As you are gathering requirements, you can subject them to analysis. Does the
requirement in question conflict with others? What is its priority? Where did it come
from? Does it need further clarification?

Analysis is ability to draw inferences from requiremenst and represent them in a

structured way. Structures themselves may vary based on what is being analysed. It is
very tough to draw boundaries between analysis and requirements gathering as they both
use the same abstractions many a time.

One could argue that analysis yields data storage structures and workflow structures etc.
However, one would think that these are not the only outputs from analysis.

==Use Cases==
Once the vision and scope of a engineering project has been established the requirements
gather process begins. One tool for communicating between the customer, analyst,
developers, and testers is a set of Use Cases. A Use Case typically has a name, a short
description, and then a number set of steps which a user would go through to accomplish
a task. Use cases are sometimes grouped together in a [[UML]] or other format of
diagram depicting users, the system, external entity and specific use cases.
===Granularity===
Use Cases are typically coarse-grained and don't dive into every detail and functional
requirement of the system. A business person or software engineer should be able to read
through all of the use cases and get an idea of the entire scope of what the project will
deliver.

===Formality of Use Cases===

Agile driven projects may skip these cases, or at least only record the attributes discussed
above. Plan driven methodologies may give additional attributes to Use Cases such as
alternative paths after covering the main steps, trace requirements covered by the use case
back to their source, and have an error handling section for each use case.

THE STAGES OF ANALYSIS

Analysis is typically accomplished in two stages. The first stage, Business Analysis
includes an in-depth examination of the customer's present set of business or
manufacturing processes and procedures with an eye toward how they might be improved
by automation. The second stage, Systems Analysis consists of an examination of the
proposed improvements and a recommendation on what computer environment and
software technology is best suited to accomplish those improvements.

BUSINESS ANALYSIS STAGE

From the Business Analyst's in-depth understanding of the customer's present
environment, he or she creates a set of "business use-cases", which are short descriptions
of the role that each of the business's "actors" perform within each process or procedure.
For instance, the waiter in a restaurant might have a use case as follows: " A. Actor
approaches customer table, introduces self and recites a description of the day's specials.
B. Actor presents a beverage menu and inquires if customer would like to order a
beverage. C. If yes, actor writes each customer's order on a drink tag and proceeds to bar
area. D. Actor presents the tag to bar-keep and makes a mental note to check back within
a customary time to see if the drink order is complete. E. If no, Actor presents a dinner
menu and helps customers to make selections. As each new party of customers is seated,
actor repeats procedure, beginning from step A." With a set of raw use-cases like the
proceeding, the business analyst can, with the customer's collaboration, examine how
each use-case might be automated and can thereby define an official system requirement
which becomes one of maybe hundreds of requirements that define the future software
application. As might be surmised, the effective Business Analyst must not only have
extensive experience with and knowledge of the business world, but must also have
expertise in the potentialities offered by modern software systems and how those systems
map to the reality of the business world.

SYSTEMS ANALYSIS STAGE

The second stage of the analysis process, Systems Analysis begins from the foundation
laid by the business analyst. From the set of business use cases and their resultant
software requirements, the Systems Analyst makes recommendations as to the most
suitable software technology to accomplish those requirements. In some cases, the
hardware environment limits choices of software technologies. For instance, in the
restaurant scenario, above. The customer might be adamant about providing the waiter
with a handheld device to replace the drink tag and to make the trip to the bar
unnecessary before the drink order is ready to serve. In such a case, the systems analyst
might be constrained to using only those operating systems and APIs that are supported
on the preferred handheld device.
Once the programming and run-time environment is decided, then the systems analyst
can begin turning the business use-cases and requirements into a set of "system use-
cases," which are descriptions of how the actors will interact with the proposed system.
Those system use-cases, taken together now comprise the actual blueprint that will be
used by software architects to begin laying out the classes or other software modules that
will define a road map for the software coding and development process which follows.

==Specification==
Specification is the task of precisely describing the software to be written, in a
mathematically rigorous way. In reality, most successful specifications are written to
understand and fine-tune applications that were already well-developed. Specifications
are the most important for external interfaces that must remain stable.

==Requirements Management==
Once you have gathered requirements, captured them into a specification, and the
customer agrees with it, it is possible to take a snapshot or baseline of the project
requirements. This allows one to manage existing requirements and process new
incoming ones. The specification is placed under configuration management, such as a
tool like CVS so that the requirements can be versioned and tracked.

===Rejecting Requirements===
It is important to reject requirements that
* Don't fit within the project scope
* Cannot show a positive return on investment
* Won't make the system competitive
* Aren't technically feasible

A requirement rejected doesn't have to be further analyzed, implemented, documented, or

tested. Every requirement costs the company and must be thought through.

===Change Control===
Regardless of whether your methodology is agile or plan driven, you should create some
form of change control to process new requirements. Failure to do so may lead to project
failure due to scope creep, project overruns, poor quality, or high costs. Change control
can be as simple as a development manager reviewing specification, to an elaborate tool
supported process with forms and a board of people with change control authority.

Lack of communication about changes to a specification can lead to costly wasted work
by developers, testers, or analysts. The time it takes to change one requirement in a
specification, may cost 100 times the person hours to realize the decision.
==Design and Architecture==
Design and architecture are the activities involved in specifying how the software will
actually work. This phase frequently described as being divided into two main phases,
which might be described as "business design" and "technical design". Business design
generally specifies the "why" of the system, indicating how data will be used and how it
will flow. Technical design generally specifies the "how" of the system, or how its
components will be arranged, what their features will be, and what kind of hardware the
system will require. These two phases can often be conducted roughly simultaneously,
with business design usually starting first and technical design ending last.

Of all of the phases, the design phase can often consume the most time, and many
engineers consider it the most important. A poor design can cause the failure of a project,
even after considerable resources are spent during the construction phase of the project
building it. It is important for the design and architecture of the system to be complete
enough that it can be validated and then used to develop the system.

==Coding==
Reducing a design to code may be the most obvious part of the software engineering
process, but it is not necessarily the largest portion. In fact, many software engineers
only work on the analysis and design process, then the coding work is handed off to
computer programmers to implement. This trend is increasing in many companies, where
software engineers are hired domestically and the implementation is out-sourced to a
country where programming labor is less expensive. In spite of this trend, many software
engineers still go through the entire process and do coding as well as design.

[[Computer_programming|Coding Wikibook]]

==Testing==
The purpose of testing is not only to prove that the code performs in accordance with the
design specifications, but to prove that it does not fail when subjected to undefined
inputs.

There are several types of testing. '''Unit testing''' tests one module of code for correct
inputs, outputs, and functionality. '''System testing''' tests all the modules of a software
system together. '''User acceptance testing''' is a form of systems testing to see if not only
the system works, but it meets the requirements of the business user. '''Regression
testing''' is testing performed after a system change to make sure that all system features
are still present after the change.

To perform systems and verifications testing, '''Use cases''' are developed. These cases
describe a user action or a specific feature of the system. These cases are very useful
during the construction phase of the system, and are usually specified as a deliverable of
the design phase. The use cases are generally gathered into ''test scripts'' which describe
testing activities in a reproducible way. These scripts may be executed manually by
testers, or they may be executed by automated testing software.
Generally speaking, it is an accepted industry practice for system testing and validation to
be performed by a separate person, team, or department, or in some cases, by an outside
entity. Testing is considered a specialized skill, with a skill set that is very different from
system development. It also is generally considered a bad practice for software
developers to test their own systems, since they can form habits that do not exercise the
system thoroughly, and because they can frequently test around system failures.

==Documentation==
An important (and often overlooked) task is documenting the internal design and external
functionality of software for the purpose of future maintenance and enhancement.

[http://en.wikipedia.org/wiki/Software_documentation Software documentation]is

important. Without documentation, software can be unusable, because the end user does
not know how to operate a program. Without documentation, an application can be
incorrectly installed on a server, causing components to fail. Documentation is most
important for external interfaces.

There are several means by which software can be documented, including flowcharts,
deployment guides, user's manuals, and maintenance manuals.

Development team members may write their own documentation, or a professional

technical writer may write or edit the documents for readability and style.

It's important to note that testing is or should be done during or at the end of every stage.
If this is not done, inputs into the next stage can not be very complete. Documentation
may also be sketchy or none existent.

==Maintenance==
Maintaining and enhancing software to cope with newly discovered problems or new
requirements can take far more time than the initial development of the software. Not
only may it be necessary to add code that does not fit the original design but just
determining how software works at some point after it is completed may require
significant effort by a software engineer. About 2/3 of all software engineering work is
maintenance, but this statistic can be misleading. A small part of that is fixing bugs. Most
maintenance is extending systems to do new things, which in many ways can be
considered new work. Similarly, about 2/3 of all civil engineering, architecture, and
construction work is maintenance in a similar way.

What is software engineering?

A systematic approach to the analysis, design, implementation and maintenance of
software.

Software engineering is the engineering discipline through which software is developed.

Commonly the process involves finding out what the client wants, composing this in a
list of requirements, designing an architecture capable of supporting all of the
requirements, designing, coding, testing and integrating the separate parts, testing the
whole, deploying and maintaining the software.
Programming is only a small part of software engineering.

The discipline is still in its infancy (=early stage of growth/development) as an

engineering discipline. We haven't had enough experience, nor gathered enough
empirical data to systematically understand and predict the life-cycle of a software
project.

The Software Engineering Body of Knowledge (SWEBOK) divides software engineering

into 10 knowledge areas:

1. Software requirements
2. Software design
3. Software construction
4. Software testing
5. Software maintenance
6. Software configuration management
7. Software engineering management
8. Software engineering process
9. Software engineering tools and methods
10. Software quality

[edit] The content of the field

Note: the following summaries are originally from Wikipedia. These are here only
temporarily. The titles aren't final, nothing on this page is final yet(or even near final).

[edit] Vision and Scope

The practice of software engineering in the corporate or industrial sector, starts with the
business and ends with the business. Although computers, programming languages, and
creative problem solving are what fill the engineer with interest in the field, without
servicing and enabling the user, the exercise would be pointless. Thus the first stage in
any software engineering process, is the Vision and Scope document, or some equivalent
meeting.

A vision of the system to be built is described by the user or Product Champion. The
business context that it will service is described. The key stakeholders are enumerated
including their interests, risks, etc. The success conditions are listed, so that it is
understood what will be completed and how to measure success.

Business opportunities are discussed, to justify why the project should be invested with
the blood, sweat, and tears of programmers, testers, project managers, and program
managers. The Scope of the project is made clear and if it is to be in phases, the scope of
each phase at a high level is laid out. The priorities of the project are recorded.

With an understanding of the business' vision, the engineers begin to ask questions.

[edit] Requirements Analysis

Extracting requirements of a desired software product is the first task in creating it. This
process is called requirements elicitation. While customers probably believe they know
what the software should do, it may require skill and experience in software engineering
to recognize incomplete, ambiguous or contradictory requirements.

Compounding this problem is the absence of formal abstractions. A civil, mechanical

engineer has a plan, elevation, sections to refer to and these make good sense to both the
author and reader of these abstractions. However, while (E-R) or object diagrams,
process flow diagrams, data flow diagrams are abstractions that have been used and built
on, many of these are not universally used or practiced.

Besides, considerable effort goes into repairing and enhancing existing systems.
Engineering required here is a mix of reverse and forward engineering in the sense that
requiremnts definitions refer to a set of circumstances that already exist and these
circumstances have to be stated in unambiguous terms as well.

Perhaps, lack of universally accepted abstractions make life difficult for software
engineers and some people have even argued that software production process is closer to
art rather than engineering!

Of late, people have started using prototypes in various degrees of working. Screen shots
and report layouts are non working prototypes and form the basic level of prototyping
and increasing sophistication is built in wherever possible. Making prototypes is always
more time consuming than not making one. Thus, this practice is not always utilised.

[edit] Analyst Role

The role of analyst can be fulfilled typically by three types of people. A technical project
manager, a software engineer, or a dedicated analyst. In some organizations it is
unthinkable to engineers that they would serve the analyst role, as they are "technical"
and would consider dealing directly with the customer unthinkable. This is purely a
cultural stance that varies between companies and organizations. It is also quite common
for software engineers to work closely with the business people and customers associated
with a project, and this programmer/analyst role can be quite beneficial to the projects
success rate.
As you are gathering requirements, you can subject them to analysis. Does the
requirement in question conflict with others? What is its priority? Where did it come
from? Does it need further clarification?

Analysis is ability to draw inferences from requiremenst and represent them in a

structured way. Structures themselves may vary based on what is being analysed. It is
very tough to draw boundaries between analysis and requirements gathering as they both
use the same abstractions many a time.

One could argue that analysis yields data storage structures and workflow structures etc.
However, one would think that these are not the only outputs from analysis.

[edit] Use Cases

Once the vision and scope of a engineering project has been established the requirements
gather process begins. One tool for communicating between the customer, analyst,
developers, and testers is a set of Use Cases. A Use Case typically has a name, a short
description, and then a number set of steps which a user would go through to accomplish
a task. Use cases are sometimes grouped together in a UML or other format of diagram
depicting users, the system, external entity and specific use cases.

[edit] Granularity

Use Cases are typically coarse-grained and don't dive into every detail and functional
requirement of the system. A business person or software engineer should be able to read
through all of the use cases and get an idea of the entire scope of what the project will
deliver.

[edit] Formality of Use Cases

Agile driven projects may skip these cases, or at least only record the attributes discussed
above. Plan driven methodologies may give additional attributes to Use Cases such as
alternative paths after covering the main steps, trace requirements covered by the use case
back to their source, and have an error handling section for each use case.

THE STAGES OF ANALYSIS Analysis is typically accomplished in two stages. The

first stage, Business Analysis includes an in-depth examination of the customer's present
set of business or manufacturing processes and procedures with an eye toward how they
might be improved by automation. The second stage, Systems Analysis consists of an
examination of the proposed improvements and a recommendation on what computer
environment and software technology is best suited to accomplish those improvements.

BUSINESS ANALYSIS STAGE From the Business Analyst's in-depth understanding of

the customer's present environment, he or she creates a set of "business use-cases", which
are short descriptions of the role that each of the business's "actors" perform within each
process or procedure. For instance, the waiter in a restaurant might have a use case as
follows: " A. Actor approaches customer table, introduces self and recites a description of
the day's specials. B. Actor presents a beverage menu and inquires if customer would like
to order a beverage. C. If yes, actor writes each customer's order on a drink tag and
proceeds to bar area. D. Actor presents the tag to bar-keep and makes a mental note to
check back within a customary time to see if the drink order is complete. E. If no, Actor
presents a dinner menu and helps customers to make selections. As each new party of
customers is seated, actor repeats procedure, beginning from step A." With a set of raw
use-cases like the proceeding, the business analyst can, with the customer's collaboration,
examine how each use-case might be automated and can thereby define an official system
requirement which becomes one of maybe hundreds of requirements that define the
future software application. As might be surmised, the effective Business Analyst must
not only have extensive experience with and knowledge of the business world, but must
also have expertise in the potentialities offered by modern software systems and how
those systems map to the reality of the business world.

SYSTEMS ANALYSIS STAGE The second stage of the analysis process, Systems
Analysis begins from the foundation laid by the business analyst. From the set of
business use cases and their resultant software requirements, the Systems Analyst makes
recommendations as to the most suitable software technology to accomplish those
requirements. In some cases, the hardware environment limits choices of software
technologies. For instance, in the restaurant scenario, above. The customer might be
adamant about providing the waiter with a handheld device to replace the drink tag and to
make the trip to the bar unnecessary before the drink order is ready to serve. In such a
case, the systems analyst might be constrained to using only those operating systems and
APIs that are supported on the preferred handheld device. Once the programming and
run-time environment is decided, then the systems analyst can begin turning the business
use-cases and requirements into a set of "system use-cases," which are descriptions of
how the actors will interact with the proposed system. Those system use-cases, taken
together now comprise the actual blueprint that will be used by software architects to
begin laying out the classes or other software modules that will define a road map for the
software coding and development process which follows.

[edit] Specification
Specification is the task of precisely describing the software to be written, in a
mathematically rigorous way. In reality, most successful specifications are written to
understand and fine-tune applications that were already well-developed. Specifications
are the most important for external interfaces that must remain stable.

[edit] Requirements Management

Once you have gathered requirements, captured them into a specification, and the
customer agrees with it, it is possible to take a snapshot or baseline of the project
requirements. This allows one to manage existing requirements and process new
incoming ones. The specification is placed under configuration management, such as a
tool like CVS so that the requirements can be versioned and tracked.

[edit] Rejecting Requirements

It is important to reject requirements that

• Don't fit within the project scope

• Cannot show a positive return on investment
• Won't make the system competitive
• Aren't technically feasible

A requirement rejected doesn't have to be further analyzed, implemented, documented, or

tested. Every requirement costs the company and must be thought through.

[edit] Change Control

Regardless of whether your methodology is agile or plan driven, you should create some
form of change control to process new requirements. Failure to do so may lead to project
failure due to scope creep, project overruns, poor quality, or high costs. Change control
can be as simple as a development manager reviewing specification, to an elaborate tool
supported process with forms and a board of people with change control authority.

Lack of communication about changes to a specification can lead to costly wasted work
by developers, testers, or analysts. The time it takes to change one requirement in a
specification, may cost 100 times the person hours to realize the decision.

[edit] Design and Architecture

Design and architecture are the activities involved in specifying how the software will
actually work. This phase frequently described as being divided into two main phases,
which might be described as "business design" and "technical design". Business design
generally specifies the "why" of the system, indicating how data will be used and how it
will flow. Technical design generally specifies the "how" of the system, or how its
components will be arranged, what their features will be, and what kind of hardware the
system will require. These two phases can often be conducted roughly simultaneously,
with business design usually starting first and technical design ending last.

Of all of the phases, the design phase can often consume the most time, and many
engineers consider it the most important. A poor design can cause the failure of a project,
even after considerable resources are spent during the construction phase of the project
building it. It is important for the design and architecture of the system to be complete
enough that it can be validated and then used to develop the system.

[edit] Coding
Reducing a design to code may be the most obvious part of the software engineering
process, but it is not necessarily the largest portion. In fact, many software engineers only
work on the analysis and design process, then the coding work is handed off to computer
programmers to implement. This trend is increasing in many companies, where software
engineers are hired domestically and the implementation is out-sourced to a country
where programming labor is less expensive. In spite of this trend, many software
engineers still go through the entire process and do coding as well as design.

Coding Wikibook

[edit] Testing
The purpose of testing is not only to prove that the code performs in accordance with the
design specifications, but to prove that it does not fail when subjected to undefined
inputs.

There are several types of testing. Unit testing tests one module of code for correct
inputs, outputs, and functionality. System testing tests all the modules of a software
system together. User acceptance testing is a form of systems testing to see if not only
the system works, but it meets the requirements of the business user. Regression testing
is testing performed after a system change to make sure that all system features are still
present after the change.

To perform systems and verifications testing, Use cases are developed. These cases
describe a user action or a specific feature of the system. These cases are very useful
during the construction phase of the system, and are usually specified as a deliverable of
the design phase. The use cases are generally gathered into test scripts which describe
testing activities in a reproducible way. These scripts may be executed manually by
testers, or they may be executed by automated testing software.

Generally speaking, it is an accepted industry practice for system testing and validation to
be performed by a separate person, team, or department, or in some cases, by an outside
entity. Testing is considered a specialized skill, with a skill set that is very different from
system development. It also is generally considered a bad practice for software
developers to test their own systems, since they can form habits that do not exercise the
system thoroughly, and because they can frequently test around system failures.

[edit] Documentation
An important (and often overlooked) task is documenting the internal design and external
functionality of software for the purpose of future maintenance and enhancement.

Software documentationis important. Without documentation, software can be unusable,

because the end user does not know how to operate a program. Without documentation,
an application can be incorrectly installed on a server, causing components to fail.
Documentation is most important for external interfaces.

There are several means by which software can be documented, including flowcharts,
deployment guides, user's manuals, and maintenance manuals.

Development team members may write their own documentation, or a professional

technical writer may write or edit the documents for readability and style.

It's important to note that testing is or should be done during or at the end of every stage.
If this is not done, inputs into the next stage can not be very complete. Documentation
may also be sketchy or none existent.

[edit] Maintenance
Maintaining and enhancing software to cope with newly discovered problems or new
requirements can take far more time than the initial development of the software. Not
only may it be necessary to add code that does not fit the original design but just
determining how software works at some point after it is completed may require
significant effort by a software engineer. About 2/3 of all software engineering work is
maintenance, but this statistic can be misleading. A small part of that is fixing bugs. Most
maintenance is extending systems to do new things, which in many ways can be
considered new work. Similarly, about 2/3 of all civil engineering, architecture, and
construction work is maintenance in a similar way.

[edit] Applied Software Engineering

The process of software engineering differs between different software types. Building a
word processor has differed requirements and design methods than building a 3D first
person shooter. These sections cover the differences and unique properties of the
different software types.

[edit] SE on Application software

[edit] SE on Server Software
Software engineering for server software is more complex then development for the
desktop computers. A server is more complex, has more requirements and features then
an ordinary, consumer system. Server software can have client-server as well as central
architecture. Development and testing of server software is also different from the
development and testing of the desktop software. Not every programming language is
suitable for implementation of server software. In conclusion, SE on server software
requires special methods and processes to successfully complete.
The main reason server software is more complex is that communication between 2
computers -- the server and the client -- is inherently more complex and prone to failure
than communication between parts of a program running on a single computer.

[edit] SE on Simulations
[edit] Scientific and engineering simulations

[edit] Games

Designing software for gaming simulations can be quite challenging, since it requires a
diverse background in software. For example, a game designer might have to write
software that simulates physics as well as software that renders 3-dimensional images.
However, many software engineers in the gaming industry are able to use 3rd party
engines that make their job much easier. Nonetheless, they must follow the software
engineering process closely, since small issues in the software can make the product fail
in the consumer market. Writing software for games is a high-risk industry and only a
small percentage of games are financially successful.

[edit] SE on Embedded software

Software engineers that work with embedded computer systems need more knowledge of
hardware than most software engineers, since embedded systems typically introduce
more constraints on memory availability and processing power than, say, gaming PCs.
Designing software for embedded systems can indeed be challenging, since most
embedded processors cannot handle the overhead produced by compiling high-level
languages. This often forces software engineers to implement embedded software, at least
partially, in assembly.