Uwe Hansmann

Web Application Servers

In recent years, the World Wide Web has evolved from a network of static information to a dynamic application deployment and management system.

The Service Layer

The OpenCard Framework service layer shields the application programmer from smart card details. This layer abstracts the smart card and on-card applications. Figure 10.1 shows the general structure of this layer.

Overview of Agile Software Development

Agile thinking is an attempt to simplify things by reducing complexity of planning, by focusing on customer value, and by shaping a fruitful climate of participation and collaboration. There are a vast number of methods, techniques, best practices, that claim to be “agile.” In this chap. we want to give an overview of the most common ones. The five principles of a fractal team, which we introduced in Chap. 1, apply to most of them: self-similarity, goal orientation, self organization, self improvement, and vitality are cornerstones when implementing an organization capable of executing software projects in an agile way. The desire to establish flexible and efficient development processes which produce high quality results is not new and has not only been applied to software development: More than two decades ago, the manufacturing industry underwent dramatic changes, when the traditional production concepts of Taylor and Ford were challenged by extremely successful Japanese enterprises such as Toyota. The Western hemisphere was puzzled at how the competition from Far East seemed to be able to produce better quality at lower cost and quickly began to outperform the rest of the world. What happened? What was the secret of the amazing efficiency and innovation?

Mix and Match

Typically, in startup companies without a strong hierarchy, a small group of people kicks off projects quite informally. They simply begin to work and continue to evolve their ideas towards a common vision. Successful startups gain competitive advantages because they are able to adapt to customer needs in a nonbureaucratic way. They follow a lightweight, ad-hoc development approach and avoid too large a burden of processes, documentation, management control, or project planning. They operate extremely cost-effectively and focus on implementing customer value as quickly as possible, in order to generate some return of investment. The progress can be impressive, as the most relevant and attractive use cases will be implemented first. Teams are rather small, everybody knows each other, and everyone is in it together. People in startup companies also tend to have a strong passion for their work and show an entrepreneurial attitude. The future of each team member is strongly tied to the success of the project. Over time, the product they are developing may be a tremendous success. Things will change in such a startup company once the team starts growing rapidly. Different teams will be established to focus on different topics. This work-split happens naturally, without a master plan. Maybe there will be goals that define the overall direction. And maybe everything we wrote about management by objectives and self-organizing, horizontal teams will be nicely implemented in that company.

What Pervasive Computing Is All About

The upcoming industrialization of the 19th century was a result of the steam engine, which was developed by James Watt. Energy was used to extend the power and strength of the workers and soon became a key factor of the economy. Since generated energy could not be transmitted over distances at those times, the engines and machines were concentrated at those locations where energy was produced. Large mills and plants were the typical symbol of that era.

Smart Card Readers and Terminals

To write and read data to a smart card or to execute a command on a smart card, it is necessary to have a physical connection with the card. To make the connection with a contact card, it has to be inserted in a smart card acceptance device. In this chapter we give an overview of the different types of card acceptance devices.

Summary and Wrap-Up

To become agile, it is not sufficient to just install a handful of new tools, apply some new methods, and rename your milestones to “iteration exit.” Agile will challenge the way your organization is set up, and it will affect the daily work of each individual. Thinking horizontally across boundaries of teams, geographies, and organizations is a change of culture and mindset. Part of embracing your highly dynamic environment is to accept that you will learn as you go by prototyping and evolving your deliverables over time. Change is always part of the game. Ask for feedback and adopt! You will continuously integrate your work, while continuously stabilizing and evaluating whatever you are doing – regardless of whether you are planning, designing, or implementing. Staying focused on customer value and proceeding in a sustainable pace will drive efficiency. Yes, agile development is a lot about philosophy, and it needs the commitment of the entire organization. Adopting agile will take a lot of hard work and considerable time until you can reap its benefits.

Considerations on Teaming and Leadership

So far we have discussed a vast range of best practices, techniques, guidelines, and tools that are typically associated with agile thinking. By now, one important question is likely to come up: How can we apply these to a real-life project? What are the considerations that need to be taken into account? In the next three chap. we will look at specific aspects that need to be considered in order to make your agile software development project successful. We have structured them into three categories: Teaming and leadership (Chap. 5) Architecture, design, and planning (Chap. 6) Execution, implementation, and test (Chap. 7)

The Flaw in the Plan

Once upon a time, Gustav II Adolf, the king of Sweden gave orders to build the biggest war ship that would ever set sail on the oceans of his time: The Vasa. Among the planned key features of the vessel were two decks stuffed with cannons. Such a power of arms has been unprecedented. The king hired the best ship makers from all over Europe. An impressive gathering of skills, talent, and ambition took place in a shipyard near Stockholm, Sweden. The admiral of the fleet personally took over the project management. The construction was led by an architect from the Netherlands and the designated captain of the new ship. In those days, there were no construction blueprints or static calculations. The architect applied proportions of other existing ships and supervised the work of the craftsmen in the shipyard personally. During a period of 2 full years, the team created the huge ship from 1,000 oak trees. The afterdeck raised high above the waterline and had been enriched with precious ornaments to honor the king: There were beautiful wooden statues resembling roman warriors. There were lions, mermaids, and images of Greek gods. The craftsmen attached the huge masts and loaded the 64 heavy cannons. The caliber of the cannons on the upper deck had been increased late in the project, because there had been rumors that the enemy was attempting to build a similar ship. Despite this significant change of the weight distribution, no replanning of the project occurred. The architect continued to apply the proven proportions to the Vasa’s hulk, which have worked so well for all of his other ship constructions in the past.

Traditional Software Development

Large projects from the past must already have had some sort of project management, such the Pyramid of Giza or Pyramid of Cheops, which were built more than 2,500 years BC. We cannot believe that those types of projects were possible without some sort of project management. But at least we are not aware of the project management practices that were used back then. The 1950s mark the beginning of project management in the modern sense. Before that, projects were already using Gantt charts (developed by Charles Gantt), but during the 1950s more formal project management techniques were developed, documented, and made available to the community (Fig. 2.1). PERT, Program Evaluation and Review Technique, one of the first project management scheduling techniques, was developed by Booz Allen Hamilton Inc. as part of the Polaris submarine missile project. It was developed to schedule and coordinate large projects. What you see in Fig. 2.2 is a CPM Network chart created with Microsoft Project. In this flavor the nodes represent tasks; in the original PERT chart the nodes represent events or milestones. Around the same time, the Critical Path Method (CPM) was developed at DuPont, originally to plan the shutdown and start-up of chemical factories before and after maintenance. CPM is very similar to PERT. In CPM, the nodes represent activities or events (an event is an activity with duration of zero) and dependencies are represented by arrows between two nodes. Using Earliest Start- and Finish-time as well as Latest Start- and Finish-Time, one can calculate the critical path in a CPM network diagram.