Scrum—Mastering the Chaos
by John W.
Stout and Peg Bogema
A common complaint about the software development process is that
is it conceived to be inflexible. Sample complaints include:
"I have to say exactly what I want and then I get exactly what I
said I wanted. But sometimes I didn’t really know what I wanted!"
or
"I know what I want right now but if my needs change or the
market changes, I may want to change, too. Why can’t I?!"
There are many variations on this theme.
There is a new approach to the management of the software
development process that appears to give relief to customers. That’s
right—customers.
It is called Scrum. Not a very descriptive term—unless you
happen to be a rugby fan: scrum is the word for eight rugby
teammates packing together to move the ball down the field. In
software development, it evokes the image of a small, tight-knit
team working very closely together to accomplish a goal.
The Scrum methodology is based on the idea that software
development processes are empirical (as opposed to defined
and predictable). These empirical processes are observed to be
complex, unpredictable and changing—in other words chaotic.
With Scrum, the customer prioritizes its needs and the
development team picks items from the list that can be delivered in
approximately one month. At the end of the one-month period, which
is called a sprint, the team delivers. End of story.
The principles of Scrum include small teams, adapting the product
to ensure it is the best possible, frequent builds, partitioning of
work, constant ongoing testing and documentation, ability to declare
that the product is done when it is necessary to do so.
The team leader is the Scrum Master who, among other
things, reduces project risk by ensuring incremental deliverables
are met, removing obstacles and tracking progress.
The beauty of Scrum is that the customer is always in the
driver’s seat. At the beginning of each sprint, the customer gets to
re-prioritize. So your needs on May 1st
may be radically different from your needs the last time you met
with the team on April 1st—but the team is going
to be completely accepting of that. Furthermore, every delivery is
relatively small; so if what you requested isn’t what you really
wanted, changing course is usually straightforward and there is
little waste, if any.
Well executed Scrum projects have demonstrated a 600%
productivity gain over older methods.
Whether you are hiring an outside software development team or
are a "customer" of a software development team within your own
company, Scrum is worth a good look. Suggested reading:
Agile
Development with Scrum on SQLServerCentral.com
What is
SCRUM? on TheCodeProject.com
Or poke around at controlchaos.com.
John W. Stout is the founder and president of
Stout Systems. He has twenty-five year's experience in the software
industry. He is also sought after as a technology speaker,
presenting sessions at developer conferences and user groups. E-mail
.
Peg Bogema is the Executive Project Manager of
Stout Systems Development. E-mail
.
Overview of Embedded Linux
by David B.
Rein
Over the past several years the nature of embedded systems has
changed significantly. Systems have expanded from micro-controllers
with simple polling loops to proprietary real-time operating systems
and—in a surprising number of cases—systems based on standard
processors and form factors using full-featured operating systems
like Windows and Linux. This article explores some of the issues
involved in developing a Linux-based embedded system.
I recently worked on the design and development of a system to
automate the control of building lighting. The controller
requirements included being totally self contained without front
panel display or buttons. Some other key specifications were:
· 4 high-speed serial ports 120K baud to 256K baud
· FLASH read-only file system
· low cost hardware
· field upgradeable software
· remote user interface
· 24/7 operation
The first two requirements tend to push a project to a custom
micro-controller design since standard PCs do not support the serial
rates and FLASH-only file systems. But a custom design is expensive,
both in hardware and software development.
In this type of project the designer can choose the components
and tailor the operating environment to exactly match the
requirements. Then controller hardware is designed, built and tested
while the software is constructed virtually from the ground up. A
realtime operating system can supply a framework for the
application, but most hardware functions require writing device
drivers. This process can take easily three to six months before
starting on the application development. This design tends to be
brittle, taking significant effort to incorporate new features and
peripherals.
Two things changed the course of this design, making an X86
processor and Linux viable choices. The first was the availability
of low cost USB-to-serial chips that could support the high baud
rates without loading down the processor. The second was very low
cost X86 motherboards. Once those were selected, Linux became a
logical choice.
To start development required nothing more than installing the
target distribution of Linux on a PC. Porting to the target system
required a hard drive for initial testing.
The advantages of Linux for this project were:
· Open source
· Fully configurable
· Low upfront costs and no per system royalties
· Broad range of support sources
The disadvantages were:
· GPL and other open source license requirements
· Memory and storage footprint
A significant disadvantage of Linux can be that it is licensed
under GPL (GNU Public License). This license requires that all code
that is derived from GPL code also be licensed under GPL and thus be
open source. Most interpret this to apply to all kernel code,
including device drivers, since it is virtually impossible to
develop in the kernel environment without using some GPL code. This
can be a serious issue when integrating proprietary hardware or
protocols. Note that application code that only links GPL libraries
and header files and does not include any GPL source is usually
covered by the LGPL (Lesser or Library GPL) and does not need to be
licensed as GPL or be open sourced.
The minimum storage and RAM requirements for a simple embedded
Linux controller are about 16MB. A more complex system without GUI
can easily use 250MB of storage and 64 to 256MB RAM. This is well
beyond the on-chip resources of most embedded controllers and
therefore requires external FLASH and RAM—significantly increasing
system costs and complexity.
Neither of the disadvantages affected this project: there was
minimal kernel code developed, and the motherboard used inexpensive
SDRAM and CompactFlash that looked like a hard drive.
The software design process for Linux was similar to other
application development. Because the BIOS and Linux handle so much
of the boot and hardware issues, most of the design effort was
focused on the application. It incorporated the normal tasks of
application partitioning, inter-process communications and remote
processor communications. But with the broad range of functionality
that Linux provides, the design resulted in a system vastly more
flexible and scalable than could have be done with RTOS-based
development.
A RTOS-based system would have been a single binary image that
included all tasks, device drivers and RTOS. Significant effort
would have been spent configuring the RTOS and implementing device
drivers just to be able to begin work with the processor. Debug
would have required a hardware-based interface. Each code change
would have required relinking and downloading the complete binary
image. This type of system provides no memory protection between
tasks nor between the application and kernel space, making isolation
of bugs very difficult. Memory corruption would often crash the
system.
With Linux the development process was very different, showing
the flexibility of Linux and the GNU tools.
|
GNU Tools |
Comments |
|
gcc |
The compiler tool kit, including support for many language
such as Fortran, C++, ADA and Java. This is the standard
against which most other embedded tools are compared. |
|
make |
A make utility with great features and flexibility. Don't
rebuild without it. |
|
gdb |
Command line source level debugger. Very complete, but
also very complex, which is why most everyone uses a GUI front
end. |
|
ddd |
GUI front end for gdb. Runs under X-Windows and has most
of the features one needs for debugging. |
|
cvs |
Full-featured command line version control system. It is
very easy to incorporate into scripts, or one can use a GUI
front end. |
|
Cygwin |
Stuck with Windows but want dd, ls, bash, gcc, and all the
other Linux utilities that make the command line useful and
productive? This port has it all. Often required by open
source projects to run on Windows. |
Using a standard distribution of Linux affected the ultimate
delivered system in many positive ways. The development time was
reduced and the most difficult areas such as device drivers and boot
issues were deferred until later stages, allowing early development
of the application so its infrastructure and function could be
tested and refined through most of the development cycle. Using an
RTOS environment, the boot and device drivers would have had to be
developed first, delaying application testing. Since the peripherals
used the USB stack, it was a simple step to implement USB FLASH
drives for field upgrade. Though the system was built without GUI,
the standard multi-console feature allowed giving each process its
own console window—which allows interaction with a process without
disrupting other processes. The 2.6 kernel has a choice of soft
real-time task schedulers that provided sufficient performance on a
low end system. The TCP/IP stack allowed several different modes of
inter-process communications, including a remote GUI for user
configuration and telnet like access to processes for
diagnostics.
The use of Linux in an embedded project can provide significant
advantages over more traditional approaches, especially where
standard interfaces and off the shelf products constitute the
hardware platform of the system. The benefit is in architectural
flexibility, system scalability, debug and diagnostics access and
ultimately time to market and cost. In the case of this project it
proved its value many times over.
David Rein is a software engineer and the
founder of DBR Consulting, LLC. He has been designing embedded and
real-time systems for over thirty years. E-mail
.
Graphical IDEs for Linux
|
emacs:
A highly configurable editor often used as an IDE for
development. Some love it, some hate it. The price is
right. |
|
Kdevelop: Provides
project management, editor, build management for gcc and GUI
front end to gdb. Excellent integration of GNU config tools
such as autoconfig. Has function referencing and
auto-completion. Kdevelop has some limitations. Next
release should improve on its features. Well worth
considering. |
|
| Anjuta:
Version 1.x is very basic. There is a new 2.x release in alpha
at this time that is very similar to Kdevelop. |
|
|
Eclipse: An IDE on
the grand scale. Originally developed by IBM for Java
development, now it is managed by the Eclipse Foundation. It
runs on many platforms including Linux and Windows. This IDE
supports plugins! There is a set of plugins for C/C++
development. Earlier versions of the C++ plugin would crash
when attempting auto-completion in a medium size project.
There is a new version out that might have fixed the problem.
It is open source and free (as in beer). |
|
Visual
SlickEdit: This is the only commercial product in
the list. It has Windows and Linux versions and the best
referencing and auto-completion I have found. Its very fast
even on large projects. Build environment is configured for
gcc and the GUI debugger integrates well with gdb. |
|
Recent News
Stout Systems welcomes new employees Bob Kelley, Paul Dersey,
Robert Hipple, Malcolm Miranda (Software Engineers) and Greg Lucot
(Software Engineering Manager).
