Software Process: Improvement and Practice

Towards An Agile Methodology for Building Embedded Real-Time Systems

Journal: Software Process: Improvement and Practice

Manuscript ID: draft

Wiley - Manuscript type: Research Article

Fo
Date Submitted by the
n/a
Author:

Complete List of Authors: Cordeiro, Lucas; Universidade Federal do Amazonas, Computer

r

Science; BenQ Mobile, Embedded Software Development

Barreto, Raimundo; Universidade Federal do Amazonas, Computer
Pe

Science
Barcelos, Rafael; BenQ Mobile, PC Software Development
Júnior, Meuse; Universidade Federal de Pernambuco, Computer
Science
Maciel, Paulo; Universidade Federal de Pernambuco, Computer
er

Science
Júnior, Vicente; Universidade Federal do Amazonas, Computer
Science
Re

Agile methodologies, Organizational Patterns, Embedded Agile

Keywords:
Development, Platform-Based Design, Real-time Software
vi
ew

http://mc.manuscriptcentral.com/spip
Page 1 of 10 Software Process: Improvement and Practice

1
2 Towards An Agile Methodology for Building Embedded Real-Time Systems
3
4 Lucas Cordeiro1,3 , Raimundo Barreto1 , Rafael Barcelos3 , Meuse Oliveira2 ,
5 Vicente Lucena1 , and Paulo Maciel2
6
1
7 Departamento de Ciência da Computação - Universidade Federal do Amazonas (UFAM), Brazil
8 rbarreto@dcc.ufam.edu.br and vicente@ufam.edu.br
9
2
10 Centro de Informática - Universidade Federal do Pernambuco (UFPE), Brazil
11 {mnoj, prmm}@cin.ufpe.br
12 3
13 BenQ Mobile Phones - Research and Development Center, Brazil
14 {lucas.cordeiro, raf ael.barcelos}@benq.com
15
16 February 26, 2007
17
18
19 Abstract solve the problems at hand in an empirical way [2]. An-
20 other important point is that some classes of embedded real-
Fo

21 The proposed development methodology combines agile prin- time systems may put lives or business-critical functions at
22 ciples with organizational patterns and adapts them to build risk (mission criticality). Therefore, these systems should
23 embedded real-time systems focusing on the system’s con- be treated differently from the case where the only cost of
24 straints. The hardware/software partitioning and platform- failure is the project’s investment.
rP

25 based design are used in the proposed methodology to support Based on this context, we propose a development method-
26 the embedded system designer for meeting the system’s con- ology based on the agile principles such as adaptive plan-
27 straints in an iterative and incremental way and for reducing ning, flexibility, iterative and incremental approach in or-
28 substantially the design time and cost of the product. In order der to make the development of embedded real-time systems
29
ee

to discuss the strengths and weakness of this methodology, a easier. To achieve that, this methodology is composed by
30 case study involving a pulse oximeter is also presented. best practices from Software Engineering and Agile methods
31 Keywords: Agile methodologies, Organizational Pat- (Scrum and XP) which aim at minimizing the main problems
32 terns, Embedded Agile Development, Platform-Based Design, present on the embedded software development context (i.e.
rR

33
Real-time Software. requirement volatility and risk management), and by oth-
34
ers practices that are needed to achieve embedded real-time
35
36 systems (i.e. platform-based design [3]). In this paper, the
37
1 Introduction methodology and its components (roles, process and tools)
ev

38 are described.
The micro-controllers becoming cheaper, smaller and more The remainder of this paper is organized as follows: Sec-
39 reliable make them economically attractive to be used as
40 tion 2 summarizes the related works. Section 3 overviews
computer systems in several appliances. Approximately the agile methods and patterns that were integrated into the
41
iew

3 billion of micro-controllers (µC) are sold each year and proposed methodology. Section 4 describes the proposed ag-
42
smaller µC (4-,8-, and 16-bit) are dominating the market ile methodology and section 5 shows the application of the
43
and adding value to products [1]. The embedded computer proposed methodology in the development of a pulse oxime-
44
systems are used in a wide range of system from machine ter. Finally, section 6 summarizes this paper and identifies
45
condition monitoring to airbag control systems. As the sys- the next steps from this research.
46
47 tem complexity increases, its development lifecycle is also af-
48 fected. Because of that, system development methodologies
49 must be applied in order to manage the team size, the prod- 2 Related Works
50 uct requirement (scope), and meet the project’s constraints
51 (time-to-market and costs). Embedded software development teams usually do not make
52 Nevertheless, many development methodologies that are use of development methodologies or any other more complex
53 used to produce software that runs on the personal com- software engineering concept [2]. There are different reasons
54 puters (PC’s) are not appropriate for developing embedded that explain this fact, but the main one is the developers’
55 real-time systems. This kind of system contains very differ- lack of maturity related to software engineering practices.
56 ent characteristics such as dedicated hardware and software, Nevertheless, we identified in the literature through a biblio-
57 and constraints that are not common to PC’s based systems graphical review, three different development methodologies
58 (e.g. energy consumption, execution time, memory foot- that allowed us to evaluate the state of the art in this con-
59 print). Moreover, many embedded systems engineers do not text and to support us during the definition of our proposed
60 have good software engineering skills. They have hardware approach.
development skills and often use programming languages to One of the results from this review is a paper that describes

http://mc.manuscriptcentral.com/spip
 Software Process: Improvement and Practice Page 2 of 10

1
2
3
4
the experience of applying Agile approaches to the develop- 3 A Brief Look at the Agile Meth-
ment of firmware for the Intel Itanium processor family [2].
5
In this paper, Greene identified the agile practices that his
ods and Patterns
6
team successfully applied, but he did not take into account
7 In this section, a brief look at the agile principles, methods,
8 the hardware related development, one of the main parts of and patterns that were used in the proposed methodology is
9 this kind of development. Greene only mentioned that an-
presented. It identifies the main product development and
10 other Intel team was applying agile concepts and they were
management practices of the XP and Scrum methods respec-
11 having good results. Even so, the comments retrieved from tively.
12 this paper regarding the application of agile concepts were
13 very useful during the definition of our approach since it sup-
14 ports the benefits of using agile concepts in contexts beyond 3.1 Extreme Programming
15 object oriented software development.
The most recognizable agile method is eXtreme Program-
16
ming (XP) which is very communication-oriented and team-
17 The second one is the methodology proposed by Gajski [4] oriented [6]. XP is composed of 12 core practices and some
18 which aims to develop embedded systems by formally de- of its main characteristics that were integrated into the pro-
19 scribing the system’s functionalities in an executable lan- posed methodology include:
20 guage rather than a natural language. The executable spec-
Fo

21 ification is refined through the system-design tasks of allo-

22 • Refactoring practice: The process of changing a soft-
cation, partition, and refinement. Estimators are also used ware system in such a way that it does not alter the
23 in order to explore design alternatives. Since system compo-
24 external behavior of the code and at the same time im-
nents are defined formally then components are implemented
rP

25 proves its internal structure.

by just compiling the component’s functional description into
26 machine code. This methodology has already been applied
27 • Continuous Integration practice: The code is com-
to several embedded systems projects and has influenced our piled and tested in an automated process every time it
28
proposed methodology. However, this methodology assumes is checked-in.
29
ee

that all requirements are captured before applying the par-

30
titioning algorithms. • Test-driven development practice: The unit tests
31
32 are written by the developers before coding. These unit
rR

33 Finally, Manhart and Schneider [5] related a successful in- tests are automated tests that test the functionality of
34 dustrial experience when partially adopting agile methods in pieces of the code.
35 the production of software for embedded systems. Indeed
36 they made slight modifications in a well established soft- • Coding Standard practice: Everyone involved in the
37 ware development process for the automotive branch adopt- project needs to follow the same code style. It specifies
ev

38 ing some agile elements in order to adequate their process to a consistent format for source code, within the chosen
39 new needs as flexibility and high speed software production. programming language.
40 As pointed out in the paper many other application areas
41
iew

may benefit from their experiments, nevertheless the authors XP promotes an evolutionary approach to design the sys-
42 did not presented any measurement results that could prove tem by using the first three practices described above. The
43 their expectations. main benefit of this approach is that the system grows in an
44 incremental way and it aims to reduce project’s risk and un-
45 certainty too early (risk management). Section 4 describes
46 The difference of the proposed methodology compared
how these XP practices were adapted into the proposed
47 with other methodologies can be described as follows: (i)
methodology.
48 our methodology aims to tradeoff flexibility and perfor-
49 mance by adopting highly programmable platforms, (ii)
50 hardware/software estimation and partitioning techniques 3.2 Scrum
51 are used in order to explore design alternatives and meet
the system’s constraints, (iii) by making use of the iter- Scrum is a simple and straightforward approach to manage
52
53 ative and incremental approach, the product development the software development process based on the assumption
54 can be broken in a sequence of iterations and implemented that environmental (i.e. people) and technical (i.e. tech-
55 in an incremental way, (iv) as the system functionalities in- nologies) variables are likely to change during the process [7].
56 creases iteration by iteration then the proposed methodol- Scrum is composed of 14 practices and some of its main char-
57 ogy offers clearly an iterative process where the designer can acteristics that were integrated into the proposed methodol-
58 validate the partition of a system specification produced by ogy include:
59 algorithms, (v) and last but not least, the proposed method-
60 ology adopts an adaptive planning which makes it possible • Sprint practice: The iteration is organized in 30-
to embraces changes even late in the development process. calendar-day.

http://mc.manuscriptcentral.com/spip
Page 3 of 10 Software Process: Improvement and Practice

1
2
3
• Sprint Planning practice: Consists of two meetings. and they offer patterns that help the development team de-
4
In the first meeting, the product backlog (which con- fine mechanisms for managing different versions of the work
5
tains features, use cases, enhancements, and defects) is products, develop code in parallel with other developers and
6
7 refined and re-prioritized by the product owner, stake- join up with the current state of development line, and iden-
8 holders and goals are chosen. In the second meeting, the tify what versions of code make up a particular component.
9 Scrum team figures out how to achieve the requests and
10 creates the sprint backlog that contains detailed tasks
11 to be accomplished. 4 Proposed Agile Development
12 • Sprint Review practice: The Scrum team presents Methodology
13
the results obtained at the end of each iteration by
14 The proposed methodology aims to define roles and respon-
showing the working software for the product owner,
15 sibilities and provide processes, lifecycle, practices and tools
customers and other stakeholders.
16 to be applied in embedded real-time system projects. It con-
17 • Daily Scrum practice: Daily meetings are held at tains three different processes groups that should be used
18 the same place and time with special questions to be during the system development: system platform, product
19 answered by the Scrum team. development and management.
20 The system platform processes group aims to instantiate
Fo

21 Scrum adopts the empirical process control model, i.e. the the platform for a given product. It means that the system
22 practices aim to inspect the activities and empirically deter- designer must choose the system components that will be
23 mines what to do next in order to produce the expected part of the architecture and API platforms from a platform
24 outcomes (product). The productivity and quality strongly library. After that, the system designer has still the possibil-
rP

25 depend on both skills and motivation of the people involved ity to customize the architecture and API platforms in order
26 in the process. Section 4 shows how the Scrum practices to meet the application constraints. The customization pro-
27 were adapted into the proposed methodology. cess is carried out by programming the microprocessors and
28 field-programmable gate arrays (FPGAs) integrated into the
29
ee

3.3 Patterns for Agile Software Develop- platform. The customization process is carried out by suc-
30 cessive refinements in an iterative and incremental way into
31 ment
the proposed methodology.
32 The agile patterns described by [8] can be combined with The product development processes group offers prac-
rR

33 XP and Scrum agile methods with the purpose of structur- tices to develop the application’s components and integrating
34 ing the software development process of the organizations. them into the platform. The functionalities which make up
35 These patterns are split into four different pattern languages the product are partitioned into either hardware or software
36 as follows: The project management pattern language pro- elements of the platform. The partitioning algorithms used
37
ev

vides a set of patterns that help the organization manage to carry out this task take into account the energy consump-
38
the product development, clarify the product requirements, tion, execution time, and memory size of the application’s
39
coordinate project’s activities, generate system’s build, and components. The mechanical design is also part of this pro-
40
keep the team focus on the project’s primary goals. cesses group, but it is out of the scope of this paper. The
41
iew

The piecemeal growth pattern language provides a set of partitioning technique is also applied in an iterative and in-
42
patterns that help the organization define the high-level man- cremental way.
43
agement and amount of team members per project, ensure The product scope, time, quality, and costs parameters
44
45 and maintain customer satisfaction, communicate the system are monitored and controlled by the product management
46 requirements, and ensure a common vision for all people in- processes group. These parameters also influence the system
47 volved in the product development team. The organizational platform and product development processes groups. When
48 style pattern language provides a set of patterns that help the the project starts with an infeasible project plan which needs
49 organization eliminate project’s overhead and latency, ensure corrective actions to be carried out then this processes group
50 that the organization structure is compatible with the prod- aims to get the project back on the track and ensure that
51 uct architecture, organize work to develop products by ge- the project’s parameters are met. The product management
52 ographically distributed teams, and ensure that the market processes group consists of the practices promoted by the
53 needs will be met. Scrum agile method as well as the agile patterns described
54 The people and code pattern language provides a set of in Section 3. The next subsections are concerned with de-
55 patterns that help the organization define and keep the ar- scribing the processes groups, roles and responsibilities, and
56 chitecture style of the product, ensure that the architect is the processes lifecycle of the proposed methodology.
57 materially involved in implementation, and assign feature
58 development to people in nontrivial projects. The software
4.1 System Platform Processes Group
59 configuration management pattern language is not part of
60 the organizational patterns but they were integrated into the The system platform processes group is composed of the
proposed methodology. These patterns were defined by [9] following processes: product requirements, system platform,

http://mc.manuscriptcentral.com/spip
 Software Process: Improvement and Practice Page 4 of 10

1
2
3
4
5
6
7
8
9
10
11
12
13 Figure 1: System Platform Processes Group. Figure 2: Product Development Processes Group.
14
15
16 product line, and system optimization. Figure 1 depicts
17 the processes that are related to system platform processes
18 group. The product requirements process aims to obtain the
19 system’s requirements (functional and non-functional) that
20 are relevant to determine the system platform in which the
Fo

21 product will be built. The platform instance process helps

22 the development team define the system platform by making
23 use of a set of design tools and benchmarks.
24 After defining the system platform, the product line process
rP

25
helps the development team setup the repository in which the
26
system platform components will be available to the product
27
development. This process also allows the development team Figure 3: Product Management Processes Group.
28
to implement and integrate system’s functionalities into the
29
ee

system and release new product versions into the market. Af-
30
ter implementing and integrating the system’s functionalities 4.3 Product Management Processes Group
31
32 into the product development line, the system optimization
process provides activities to ensure that system’s variables The product management processes group is composed of
rR

33 the following processes: product requirements, project man-

34 such as execution time, energy consumption, program size
and data memory size satisfy the application constraints. agement, bug tracking, sprint requirements, product line, and
35 implementation priority. Figure 3 depicts the processes that
36 are related to product management processes group. The
37
ev

product requirements process (that also belongs to the sys-

38 4.2 Product Development Processes Group tem platform processes group) aims to obtain the system’s
39 requirements (functional and non-functional) that must be
40 The product development processes group is composed of the part of the product. The project management process allows
41
iew

following processes: functionality implementation, task inte- the development team to implement the system’s require-
42 gration, system refactoring, and system optimization. Figure ments by managing the product and sprint backlog, coordi-
43 2 depicts the processes that are related to product devel- nating activities, generating system’s build, and tracking the
44 opment processes group. The functionality implementation product’s bug.
45 process ensures that test cases are created for every prod-
46 The bug tracking process allows the product leader to man-
uct’s functionality. This process helps increase the product age the lifecycle of the project’s issues (bug, task, and en-
47
quality and reduce the creation of complex functions. The hancement) and provide the needed information about the
48
task integration process provides means to integrate new im- product quality through the release notes for the end user.
49
plemented functionalities into the development line of the The sprint requirements process allows the development team
50
product without forcing the other team members to work to analyze, evaluate, and estimate the system’s functionali-
51
around it. ties before starting a new project’s sprint. This information
52
53 The system refactoring process supports the development is included into the sprint backlog which will help the devel-
54 team for identifying opportunity to improve the code and opment team partition the system functionalities into either
55 changing it without altering its external behavior. After hardware or software before starting the sprint.
56 refactoring the code, the system optimization process allows The product line process guarantees that the system func-
57 the development team to optimize small part of the code by tionalities implemented during the sprint will be integrated
58 making use of profiler tools that monitor the program and into the product development line. This process also helps
59 tells where, for instance, it is consuming time, energy, and the development team to release new product versions into
60 memory space. This process guarantees that software met- the market. The implementation priority process helps the
rics meets the system constraints. product leader manage any kind of interruptions that may

http://mc.manuscriptcentral.com/spip
Page 5 of 10 Software Process: Improvement and Practice

1
2
3
4
impact the project’s goals. This process guarantees that the 4.5 Processes Lifecycle
project’s tasks are 100 percent completed after initiated.
5 The proposed agile methodology consists of five phases:
6 Exploration, Planning, Development, Release, and Mainte-
7 nance. In the Exploration phase, the customers provide re-
4.4 Roles and Responsibilities
8 quirements for the first product release. These requirements
9 The proposed methodology involves four different roles and are included into the product backlog by the platform owner.
10 the responsibility of each role is described as follows: After that, the platform owner and product leader estimate
11 Platform Owner: Platform owner is the person who the requirements with no item larger than 3 person-days of
12 is officially responsible for the products that derive from a effort. In this phase, the development team identifies the
13 platform and application constraints and estimates the sys-
given platform. This person is responsible for defining qual-
14 tem’s metrics based on the product backlog items. With this
ity, schedule and costs targets of the product. He/she must
15 information at hand, the development team is able to define
also create and prioritize the product backlog and ensuring
16
that it is visible to everyone. Platform owner is also respon- the system platform that will be used to develop the product
17
sible for choosing the goals for the next sprint and reviewing in the next phases.
18
the product with other stakeholder at the end of iteration. In the Planning phase, the platform owner and customers
19
Product Leader: Product leader is responsible for the identify more requirements and prioritize the product back-
20
Fo

21 implementation, integration and test of the product ensur- log. After that, the development team spends one day to
22 ing that quality, schedule, and cost targets defined by the estimate the sprint backlog items and decompose them into
23 platform owner are met. He/she is also responsible for medi- tasks. The tasks that make up the sprint backlog must take
24 ating between management and development team as well as from 1 to 16 hours to be completed. Explanatory design and
rP

25 listening to progress and removing block points. If the prod- prototypes may also be developed at this phase in order to
26 uct is composed by several components and involves several help clarify the system’s requirements.
27 development teams then he/she must work very close to the In the development phase, the team members implement
28 feature leader (described below). new functionalities and enhance the system based on the
29 Feature Leader: Feature leader is responsible for man- items of the sprint backlog. The daily meetings are held
ee

30 aging, controlling and coordinating subsystem projects, pre- at the same time and place with the purpose of monitoring
31 integration projects, external suppliers that contribute to a and adapting the activities to produce the desired outcomes.
32 defined set of features. The feature leader also tracks the At the end of the each iteration, unit and functional tests
rR

33 progress and status of the feature development (deliverables, are executed in a continuous integration build. System opti-
34 integration and test status, defects, and change requests) and mization also takes place during this phase. The last sprint
35 reports the status to the product leader. provides the product to be deployed in the operational envi-
36 Development Team: Development team which may ronment.
37 consist of programmers, architects, and testers are respon- In the Release phase, the product is installed and put into
ev

38 sible for working on the product development. The amount practical use. During this phase, it usually involves the iden-
39 of work that will be addressed in the project’s iterations is tification of errors and enhancement in the system services.
40 solely up to this team. They must also assess what can be ac- Therefore, the platform owner and customers decide if these
41
iew

complished during the product development. Therefore, the changes will be included in the current or subsequent re-
42 lease. This phase aims to deliver the release product and
development team has the authority to make any decisions,
43 needed documentation to the customer. The Maintenance
do whatever is necessary to do (according to the project’s
44 phase may also require more sprints in order to implement
guidelines), and ask for any block points to be removed.
45 new features, enhancement and bug fixes raised in the release
46 If the product to be developed is small, i.e. it is composed
of few components and does not require other development phase.
47
48 teams to implement the product’s functionalities then one
49 product leader and the development is enough for the prod-
uct development. On the other hand, if the product is com- 5 Applying the Proposed Method-
50
51 posed by several components and requires other development ology
52 team to implement the product’s functionalities then another
53 role (Feature Leader) must be involved in the processes. In This section is concerned with describing the application of
54 this context, one product leader requires feature leaders to the proposed methodology in the development of the pulse
55 manage, control and coordinate components’ projects. Each oximeter equipment. We chose the pulse oximeter as a case
56 feature leader is responsible for one development team and study because it was already developed in another work by
57 may depend on the services provided by the components de- our research group using an ad hoc development methodol-
58 veloped by other development teams. Therefore, for medium ogy [10]. Therefore, we describe the pulse oximeter in this
59 and larger projects, one product leader and several feature section only as an example of the application of the proposed
60 leaders and development teams may be involved in the pro- methodology in the domain of embedded systems. Generally
cesses. speaking, the pulse oximeter is responsible for measuring the

http://mc.manuscriptcentral.com/spip
 Software Process: Improvement and Practice Page 6 of 10

1
2
3
4 CONVERSOR
5 SPECTROPHOTOMETRIC
SENSOR
LED DRIVER
PRE-AMPLIFIER DEMULTIPLEX

6
7 MICRO-CONTROLLER
UNIT DIGITAL/ANALOG
8 INTERFACE DEMODULATOR

9
10 Test Signal ATENUATOR
SELECTOR
SIGNAL/TEST
11 SELECTOR
CONTROL

12 DC Signal FILTER

13 AC Signal INTERFACE
PROGRAMMABLE
AMPLIFIER
FILTER

14 Figure 5: Evolution of the Hardware Platform.

15
16
Figure 4: Pulse Oxiemeter Architecture. 5.1 Process for Managing the Product Re-
17
18 quirements
19
20 This process would help us identify the market needs for the
Fo

21 pulse oximeter product line and manage the product require-

22 oxygen saturation in the blood system using a non-invasive ments. At the beginning of the project, we could arrange a
23 method. The architecture of this equipment is shown in Fig- brainstorming meeting in order to capture high-level require-
24 ure 4. ments of the product. After that, we could create an initial
rP

25 product backlog with the purpose of capturing more require-

26 The micro-controller controls the synchronization and am- ments and creating a first product prototype.
27 plitude of the led driver, which dispatches non-simultaneous The first project iteration would allow us to answer ques-
28 stream pulses to the infrared and red leds. Both leds gener- tions such as whether the technology needed for the system
29 ate, respectively, infrared and red radiation pulses that cross
ee

exists, how difficult it would be, check the platform perfor-

30 the finger of a patient. After crossing the finger, a photo- mance from different vendors, and test the sensor hardware.
31 diode catches the radiations level. A sequence of operations In further iterations, the sensor hardware is connected to
32 occurs until data reaches the micro-controller. Lastly, the the platform in order to measure the SpO2 e HR levels. Af-
rR

33 micro-controller performs the calculation related to oxygen ter that, the final configuration would dispense unneeded
34 saturation level based on data received, and shows the result components and combine everything on one board for eco-
35 on a display. The final product contains about 5000 lines of nomical production costs. As the hardware problems are
36 C code. Due to timing and energy constraints, the sensor found or new requirements are discovered, different versions
37 signals excitation and conditioning were implemented using of the final configuration are likely to be produced. Figure 5
ev

38 hardware components while the control algorithm and the shows the evolution of the hardware platform that is typical
39 signal conversion system were implemented in software by in many embedded real-time projects.
40 the micro-controller AT89S8252 of the 8051-family. As a requirement management strategy, we could put
41
iew

much emphasis on delivering the system’s functionalities (i),

42 The main system’s characteristics are depicted as follows: (ii), and (iii) in the beginning of the sprints. Delivering these
43 (i) the level of the oxygen saturation (SpO2) and heart rate functionalities with highest business value (the business value
44 (HR) must be shown every second, (ii) The user must be able could range from 1 lowest to 5 highest), could help our cus-
45
to change the alarm configuration, (iii) the user interface of tomer (e.g., a representative of a hospital) and the product
46
the pulse oximeter equipment must have a keyboard and a leader get feedback on functionality earlier and allow them
47
graphical display, (iv) the design of the system should be to spot any misunderstanding more quickly. At the end of
48
highly optimized for life-cycle cost and effectiveness, (v) the each iteration, the product leader and customer could verify
49
amount of software defects should be as low as possible, and if the product is still feasible or not. If the project is not
50
51 (vi) the power dissipation of the final system should be about feasible then it could be canceled just after the end of the
52 2,35 Watts. iteration (risk management).
53 If we develop a new product in which the requirements
54 If we develop this product using the proposed methodol- cannot be expected to be fully available earlier in the devel-
55 ogy then there would be about three people involved, two opment then this process would help us identify more require-
56 developers and one product leader. The product would take ments and update the product backlog as the project evolves.
57 approximately four sprints of three weeks to be developed, We could start the project with a set of functional and non-
58 tested and delivered (rough estimation). The next subsec- functional requirements. After running some project’s sprint,
59 tions describe only the processes of the proposed methodol- our understanding about the product would increase and we
60 ogy that focus on achieving the aims of the pulse oximeter could identify the requirements that were not captured at
equipment. the beginning of the project.

http://mc.manuscriptcentral.com/spip
Page 7 of 10 Software Process: Improvement and Practice

1
2
3
4
5.2 Process for Managing the Project
5 This process would help us refine and prioritize the prod-
6 uct backlog that contains the system’s functionalities. In
7 the sprint planning, the product leader and our customer
8 could choose the goals of the next sprint based on the highest
9 business value and risks of the product backlog items. After
10 that, we could have a meeting to consider how to achieve the
11 sprint’s goals and to create the sprint backlog. The sprint
12 backlog should contain only tasks in the 4-16 hour range.
13
During the system development, the sprint backlog could
14
be updated on a daily basis as the activities were being ac-
15
complished. The product leader could hold daily meetings
16
at the same place and time with the team members with the
17
purpose of monitoring and controlling the complexity of the
18
tasks. These daily meetings would provide a great feedback Figure 6: Hardware/Software Partitioning Tool for
19
20 to the product leader and create the habit of sharing the Platform-Based Design. (a) Task Graph of the System, (b)
Fo

21 knowledge. After starting the sprint, we could implement Parameters of the System Partitioner, (c) and (d) System
22 first the functional requirements and then focus on the non- Partitioner.
23 functional requirements of the system. This approach would
24 help us obtain better optimization results because we would
rP

25 be trying to optimize the global system instead of only parts (e.g., SystemC, Java, and C/C++). Nguyen et. al. [12]
26 of the system which sometimes could not lead to the global provides a tool that enables the system designer to spec-
27 optimization. ify the system model in UML and automatically convert it
28 During this phase, system’s builds could also be gener- into SystemC code [12]. After generating the code in the
29 ated on a daily basis which could help our customer clarify selected language, hardware/software estimation tools could
ee

30 the requirements and asses the risks earlier in the develop- be used to estimate the execution time and energy consump-
31 ment process. At the end of the sprint, the product leader tion. We could use the estimation tool developed by our
32 and development team could show the results of the work research group that is capable of estimating the execution
rR

33 to the customers. This meeting aims to present the product time and energy consumption based on Assembly code [13].
34 increment, technology and business situation. These arti- Therefore, after estimating the system’s metrics, we could
35 facts would help the product leader and customers decide provide this information to our hardware/software partition-
36 the goals of the next sprint. In addition, after each sprint ing tool (see Figure 6) that is being integrated into the
37 review there would be a retrospective meeting which has the Eclipse plug-in by our research group. This tool allows the
ev

38 purpose of collecting the best practices used in the sprint user to (i) enter the system’s model, (ii) enter the objective
39 and identifying what could be improved for the next sprint. function parameters such as metrics importance and con-
40 straints, (iii) select the components of the system platform,
41
iew

and (iv) find the best partition of the system.

42 5.3 Process for Instantiating the Platform Therefore, our tool would look for the best partitioning
43 that meets the design constraints. Since most design de-
This process would help us estimate the pulse oximeter met-
44 cisions are driven by constraints then the application con-
rics in order to define the system platform. To obtain the
45 straints should be incorporated into the objective function so
execution time and energy consumption metrics, we could
46 that partitions that meet constraints are considered better
47 specify the system’s functionalities in the Unified Modeling
Language (UML) by creating the class, collaboration and than those that do not meet. Our hardware/software parti-
48 tioning tool also allows the user to select an existing project,
49 sequence diagrams. UML 2.0 profile could also be used to
specify the system functionalities [11], but at the time we include other system components in the partitioning algo-
50 rithms and change the metrics’ unit. Finally, after instanti-
51 wrote this paper there was no tool available to convert the
UML 2.0 diagrams into a programming language. The main ating the platform based on the application constraints, we
52
benefits of the UML 2.0 is that it uses special stereotypes and could start developing the product.
53
54 design rules for modeling the behavior of the application and
55 platform components and it also enables their parameteriza- 5.4 Process for Implementing New Systems
56 tion.
Functionalities
57 The CASE (Computer Aided Software Engineering) tools
58 like Together and Rational Rose could be used for the en- This process would help us implement the system’s function-
59 try of the system model. After specifying the system model alities of the pulse oximeter in a systematic way. According
60 in UML using these tools, the code could be generated au- to the business value of the system’s functionalities defined
tomatically in the language selected by the system designer in the process for managing product requirements, we could

http://mc.manuscriptcentral.com/spip
 Software Process: Improvement and Practice Page 8 of 10

1
2
3
start implementing the tasks responsible for measuring the
4
SpO2 level in the patient’s blood. In order to implement this
5
functionality, we should first write the unit test for each stage
6
7 of computation. Thereafter, we should successfully compile
8 the unit test before really writing the functionality’s code. If
9 there would be compilation problems then the unit test for
10 this functionality should be fixed. We should also replace
11 the sensor data by a set of test data in order to run the unit
12 tests without needing to connect the sensor hardware to the
13 platform.
14 After successfully compiling the unit test, we could start
15 coding the functionality by following product’s coding stan-
16 dard defined at the beginning of the project. The functional-
17 ity’s code would be considered completely implemented only
18 after the team member successfully runs the unit test that
19 was created for the functionality. Therefore, it would ensure Figure 7: Analysis of Performance and Energy Consumption.
20 that the functionality would be in compliance with its speci- (a) Metrics and Options, (b) Probability Distribution, (c)
Fo

21 fication and the calculation of the SpO2 level in the patient’s Scenario Analysis, and (d) Probability Sweep (Average).
22 blood would be correctly performed.
23 An important point to take into account is that if there
24 is the need for splitting a given system’s functionality into product development line.
rP

25 different tasks then the unit tests should be created for each After integrating the code, the regression tests could be
26 code piece of the functionality. Nevertheless, these unit tests run in order to check if there is no compilation and semantic
27 can address logic but not timing. In order to find out spe- problems. If there is no problem then the refactoring would
28 cific problems related to the timing constraints of the sys- be completed. Another important point when applying the
29 refactoring process is that system functions might also be
ee

tem, we should use a domain-level testing strategy as pro-

30 posed by [14]. This technique aims to distinguish whether a moved from one system component to another, i.e., the sys-
31 problem is within a domain or in other parts of the system. tem designers might decide to move a function from software
32 For instance, if the sensor connected to the platform via se- running on one of the processors to a hardware block. For
rR

33 rial communication is not providing reliable data then the instance, the signal conditioning of the pulse oximeter could
34 problem might be either in the sensor (a hardware problem) be moved from software component to a full-custom logic,
35 or in the serial communication (timing delays). Therefore, an application-specific integrated circuit (ASIC), or recon-
36 domain-level testing is a crucial technique that helps isolate figurable logic component (FPGA). This process would also
37 lead to improve the system performance.
ev

problems at the system level such as timing constraints.

38
39
40 5.5 Process for Refactoring the Code 5.6 Process for Optimizing the System
41
iew

After implementing the system’s functionalities, we could This process would help us identify system’s variable that
42
identify in further sprints opportunities to improve an ex- could be optimized in order to meet the system’s constraint.
43
isting code. For instance, we could identify during the pulse To optimize the system’s variables, we should first estab-
44
oximeter project that the level of the SpO2 and HR func- lish the metrics and ensure that the refactoring process has
45
tionalities have some tasks in common. Both functionalities already been applied. After that, we could run our estima-
46
47 need to collect data from the sensor and identify the maxi- tion tool [13] (see Figure 7) to monitor the program and tell
48 mum and minimum signal pulses. Therefore, the application where it would be consuming time and energy. Our estima-
49 of this process would lead to elimination of duplicated code, tion tool allows the user to analyze three metrics (Energy
50 reduction of the amount of system’s functions, and improve Consumption, Power Dissipation, Execution-time) and for
51 the system performance. each metrics there three analysis options (Probability distri-
52 But before improving the code for those tasks in common, bution, Scenario analysis, Probability sweep).
53 we should first create branches in the system repository for By using this tool we could be able to find small parts
54 not breaking an existing working code. After that, we should of the program where these system’s variables could be op-
55 verify if there is some need for updating the unit test of the timized. Thereafter, we could optimize the variables under
56 functionality. If there is no need to update the unit tests attention by hand. As in refactoring, we could also carry out
57 then we could start improving the code without altering its the changes in small steps. After each step, we should com-
58 external behavior. After refactoring the code, we could run pile, test and run the estimation tool again. If the variable
59 the unit test in order to verify if the changes are working has not been optimized then we should return the changes
60 correctly. If there is no compilation problem and the unit in the version control system and continue the optimization
test dos not fail then we could integrate our changes into the process until the variables could satisfy the constraints.

http://mc.manuscriptcentral.com/spip
Page 9 of 10 Software Process: Improvement and Practice

1
2
3
4
5
6
7
8
9
10 Figure 8: Log Output Sample.
11
12
13 5.7 Process for Tracking the Product Bugs
14 This process for tracking the product’s bugs provides activi-
15 ties to manage the lifecycle of the project’s issues (e.g., bug,
16 task, and enhancement). Therefore, this process would allow
17 us to identify a new issue during the product development
18 by using a log system as depicted in Figure 8. This log sys- Figure 9: System Platform Components.
19
tem is an extension of the idea put forth by [14] which aims
20
to eliminate the overhead caused by the printf call. There-
Fo

21 line in which the product will be built. This product devel-

fore, this log system uses a circular buffer in RAM to hold
22 opment line would allow the team members to develop and
brief fixed-length text messages. In order for the develop-
23 optimize the product components.
ment team to carry out the system diagnostic, they could
24 In order to implement new system’s tasks (which may in-
write the log statement at the start and finish of an Inter-
rP

25
rupt Service Routine (ISR) and then subtract the timer to clude new requirements, enhancements and bug fixes), each
26
see how long the ISR took to execute. team member should create a branch in the product devel-
27
After identifying bugs in the code through either the log opment line. This branch would help the team member im-
28
system or the agile testing strategy described in the pro- plement the task without forcing the other team members
29
ee

cess for implementing new systems functionalities, the issue to work around it. After implementing and optimizing all
30
could be open in the bug tracking tool by any team member. system’s components that make up the product, the devel-
31
He/She should only provide the needed information in order opment team could create a release branch of the product
32
with the purpose of not interfering with the current system
rR

33 to reproduce the bug such as: summary, platform, product,

34 software version, functional cluster, component, log, and is- development.
35 sue description. After that, the issue could be automatically
36 assigned to the person responsible for the functional cluster
in which the bug was open. If the person responsible for fix-
5.9 Process for Choosing the Sprint Re-
37
ev

38 ing the issue was not able to reproduce the bug then he/she quirements
39 could talk directly with the person who opened the bug in This process for choosing the sprint requirements provides
40 order to get more information on how to reproduce it. activities to analyze, evaluate, and estimate the system’s
41
iew

functionalities before starting a new project’s sprint. This

42
5.8 Process for Managing the Product Line process would start with a meeting that would have the pur-
43
pose of determining the system’s functionalities that will be
44
The process for managing the product line provides activities implemented for the next sprint. The platform owner, prod-
45
to setup the repository, create the product development line, uct leader and customers could take part on this meeting and
46
allow the development team to integrate new system’s tasks they could choose the system’s functionalities for the sprint
47
48 into the system, and release new product versions into the based on the following criteria: (i) splitting system’s func-
49 market. This process would allow the development team to tionalities depending on the its estimates and on the load of
50 set up the system repository by populating it with the system each iteration and (ii) splitting by across data boundaries,
51 platform components which consists of the API platform and for example, selecting a subset of operations (e.g. fill in and
52 the collection of components that comprises the architecture sort array) supported for a given functionality [15].
53 platform. Figure 9 depicts the system platform components Coding stubs and mock objects should also be used in
54 that this process should manage. order to compensate for the absence of component’s func-
55 The repository should contain only the system components tionality. Because system’s components (e.g., LCD or key-
56 that are needed to derive new product lines. In other words, board driver) have little coupling to the rest of the system,
57 the development team should derive the product line (or the it would be easy to build mock objects to cover those in-
58 platform instance) from the platform by choosing a set of puts and outputs of the components. In addition, when seen
59 components from the platform library or by setting param- from the whole, having such mock objects timely available
60 eters of the library’s reconfigurable components. After that, to other subsystems might be essential for allowing the rest
they could create in the system repository the development of the system to grow optimally. Therefore, in order to en-

http://mc.manuscriptcentral.com/spip
 Software Process: Improvement and Practice Page 10 of 10

1
2
3
4
able incremental integration to happen in embedded real- References
time projects, the notion that subsystems should expect a
5 [1] P. Koopman. Embedded system design issues (the rest of
level of rework between iterations should be introduced.
6 the story). Proceedings of the International Conference on
7 Finally, after defining the system’s functionalities that fit
Computer Design (ICCD96), pages 310–317, 1996.
8 into an iteration, each team member should choose the sys- [2] B. Greene. Agile methods applied to embedded software de-
9 tem’s functionalities that he/she will be responsible for im- velopment. Proceeding of the Agile Development Conference
10 plementing during the sprint. After that, the development (ADC’04)., 2004.
11 team should use a set of design tools in order to partition [3] A. S. Vicentelli and G. Martin. Platform-based design and
12 the system functional specification into a set of system com- software design methodology for embedded systems. IEEE
13 ponents. Design and Test of Computers, 18(6):23–33, 2001.
14 [4] D. Gajski, F. Vahid, and S. Narayan. A system-design
methodology: Executable-specification refinement. Euro-
15
6 Conclusion pean Conference on Design Automation, Paris, France,
16
1994.
17 [5] P. Manhart and K. Schneider. Breaking the ice for agile
18 This paper described an agile development methodology and
development of embedded software: An industry experience
19 its application in the development of the pulse oximeter. In report. Proceedings of the 26th International Conference on
20 order to create the methodology, we chose two agile methods Software Engineering (ICSE04), page 3647, 2004.
Fo

21 XP and Scrum as well as organizational patterns named in [6] K. Beck and C. Andres. Extreme Programming Explained -
22 this paper as agile patterns. Scrum is explicitly intended Embrace Change. Second Edition, Addison-Wesley, 1999.
23 for the purpose of managing agile software development [7] K. Schwaber and M. Beedle. Agile Software Development
24 projects. On the other hand, XP is a collection of well-known with Scrum. First Edition, Series in Agile Software Develop-
rP

25 development practices. The agile patterns provide means to ment, Prentice Hall, 2002.
26 structure the software development process of organizations. [8] J. O. Coplien and D.C. Schmidt. Organizational Patterns
27 of Agile Software Development. First Edition, Prentice Hall,
When XP, Scrum and agile patterns are combined they
28 2004.
cover many areas of the system development life-cycle. How- [9] S. Berczuk and B. Appleton. Software Configuration Man-
29
ee

ever, the combination of Scrum, XP and agile patterns does agement Patterns. First Edition, Addison-Wesley, 2002.
30 not mean that they can directly be used to develop embed- [10] M. Oliveira. Desenvolvimento de Um Protótipo para a Me-
31 ded systems. Slightly changes were needed to: (i) adopt pro- dida Não Invasiva da Saturação Arterial de Oxigênio em
32 cesses and tools to optimize the product’s design rather than Humanos - Oxı́metro de Pulso. Master thesis, Center for
rR

33 take paths that lead to designs that have no chance of sat- Informatics at Federal University of Pernambuco, 2002.
34 isfying the constraints, (ii) support software and hardware [11] P. Kukkala, J. Riihimki, M. Hnnikinen, T. Hmlinen, and
35 development through a comprehensive flow from specifica- K. Kronlf. Uml 2.0 profile for embedded system design.
36 tion to implementation, (iii) instantiate the system platform Proceedings of the Design, Automation and Test in Europe
37 Conference and Exhibition (DATE’05)., 2005.
ev

based on the application constraints rather than overdesign

38 [12] K. Nguyen, Z. Sun, , and P. Thiagarajan. Model-driven soc
a platform instance for a given product, and (iv) use system design via executable uml to systemc. Proceedings of the
39
platform to conduct various design space exploration analy- 25th IEEE International Symposium on Real-Time Systems,
40
ses for performance. Page(s) 459-468, pages 459–468, 2004.
41
iew

To illustrate the use of the processes and tools of the pro- [13] M. Jr. Oliveira, S. Neto, P. Maciel, R. Lima, A. Ribeiro,
42
43 posed methodology, we described how it could be applied to R. Barreto, E. Tavares, and F. Braga. Analyzing software
develop the pulse oximeter equipment. In this case study, performance and energy consumption of embedded systems
44
we used UML notation to specify the application function- by probabilistic modeling: An approach based on coloured
45 petri nets. ICATPN 2006, LNCS 4024, pp. 261281, 2006.,
46 alities and convert them into programming languages to ap-
ply the estimation and partitioning tools. For further steps, page 261281, 2006.
47 [14] N. V. Schooenderwoert and R. Moriscato. Taming the em-
48 we are researching models that can carry enough informa-
bedded tiger - agile test techniques for embedded software.
49 tion about the ultimate physical implementation at a high Proceeding of the Agile Development Conference (ADC’04).,
50 abstraction level and achieve better results in terms of func- 2004.
51 tional correctness (e.g., Timed Petri Nets). Moreover, we [15] Mike. Cohn. Agile Estimating and Planning. Robert Martin
52 are planning experimental studies where the methodology Series, Prentice Hall, 2005.
53 will be observed while applied. After that, our goal is to in-
54 troduce the proposed methodology step-by-step at BenQ by
55 using traditional measurement framework.
56
57
58 7 Acknowledgements
59
60 This work is partially supported by Brazilian Council of Re-
search CNPq under grant number 55.3164/2005-8.

10

http://mc.manuscriptcentral.com/spip