Skip to main content
Fachgebiete
Automobil + Motoren Bauwesen + Immobilien Business IT + Informatik Elektrotechnik + Elektronik Energie + Nachhaltigkeit Finance + Banking Management + Führung Marketing + Vertrieb Maschinenbau + Werkstoffe Versicherung + Risiko
DE
EN
Themenseiten
Organisationspsychologie Projektmanagement Marketing Smart Manufacturing
Bücher
Zeitschriften
Weitere Formate
Podcasts Webinare Technik Webinare Wirtschaft Kongresse Veranstaltungskalender Awards
Jetzt Einzelzugang starten
Zugang für Unternehmen
Referenzkunden
MTZ-Fachkongress

Antriebe und Energiesysteme von morgen


Austausch von Automobil- und Energiewirtschaft

Am 14./15. Mai geht es in Chemnitz um die Mobilitätswende durch Elektro- und Wasserstofffahrzeuge.
Erweiterte Suche
Anmelden
nach oben

2005 | Buch

What Is Agility? (And Why Does It Matter?) Kapitel lesen Erstes Kapitel lesen

Agile Development with ICONIX Process

People, Process, and Pragmatism

verfasst von: Doug Rosenberg, Matt Stephens, Mark Collins-Cope

Verlag: A-Press

Enthalten in: Springer Professional "Wirtschaft+Technik" , Springer Professional "Technik" , Springer Professional "Wirtschaft"

Einloggen, um Zugang zu erhalten
insite
SUCHEN

Über dieses Buch

This book describes how to apply ICONIX Process (a minimal, use case-driven modeling process) in an agile software project. It's full of practical advice for avoiding common agile pitfalls. Further, the book defines a core agile subset so those of you who want to get agile need not spend years learning to do it. Instead, you can simply read this book and apply the core subset of techniques.

The book follows a real-life .NET/C# project from inception and UML modeling, to working code through several iterations. You can then go on-line to compare the finished product with the initial set of use cases.

The book also introduces several extensions to the core ICONIX Process, including combining test-driven development (TDD) with up-front design to maximize both approaches (with examples using Java and JUnit). And the book incorporates persona analysis to drive the projects goals and reduce requirements churn.

Inhaltsverzeichnis

Frontmatter

ICONIX and Agility

Frontmatter
Chapter 1. What Is Agility? (And Why Does It Matter?)
Summary
Taking an agile approach to your project does not have to mean abandoning up-front requirements gathering or up-front architecture and design. Often, spending the time to get the design right, based on what the customer really wants, can actually increase a project’s agility.
We aren’t suggesting that, taking this approach, requirements won’t change later on: they will. However, the level of “requirements churn” should be much lower, and what changes there are will have a lower probability of forcing a big, costly, high-risk change to the architecture.
The most visible (and probably the most often cited) reason for project failure is lack of effective user involvement, which often results in unstable requirements. One approach to fix this problem is to make the project as malleable (or agile) to the forces of change as possible. Another approach is to improve the requirements elicitation process (in other words, talk to the customer; find out what the customer really needs; use effective requirements elicitation techniques [as we describe in this book]; ask the customer hard, detailed questions; and hit the brakes if the customer doesn’t have the answers) and to model these requirements in the form of use cases.
Contrary to popular opinion, these two approaches are not mutually exclusive. In fact, combining the two approaches (traditionally seen as diametrically opposite—agile versus nonagile) should drastically reduce the risk that requirements churn places on your project.
Chapter 2. Characteristics of a Good Software Process
Summary
In this chapter, we set a primary goal for this book of identifying the sweet spot between agile, feedback-driven software processes and disciplined, plan-driven software processes. We then dissected a software process into its subcomponents and analyzed each subcomponent individually, discussing the trade-offs that you can make within each layer. We followed that with a “fact or fiction” discussion that focused on the human-centric communication issues related to software process.
The next chapter presents a brief introduction to ICONIX Process, a use case-driven approach that uses a minimalist core subset of UML. In Chapter 4, we’ll next attempt to define a minimalist core subset of agile practices. Then we’ll see how close we came to the sweet spot by exploring the design and code for our example project.
Chapter 3. ICONIX Process: A Core UML Subset
Summary
In this chapter, we summarized ICONIX Process, a minimal object-modeling analysis and design process that gets you from use cases to source code in very few steps.
In Part 2 of this book, we’ll build on the theory described in this chapter with a real-world example project, tied in of course with some agile practices. And in Part 3, we’ll show you how to extend ICONIX Process with additional software development techniques.
But first, let’s see if we can apply the same kind of “noise filter” to agility that ICONIX Process does for UML, and define a core subset of agile practices.
Chapter 4. A Core Subset of Agile Practices
Summary
In this chapter we defined a core subset of the many practices that are out there and variously defined as agile. These core practices used together complement each other and are particularly apt for use with the ICONIX object modeling process.
We also analyzed the reality of software agility versus the perception of software agility people have grown accustomed to. If an agile practice doesn’t contribute to the core goals of software agility, then it can’t reasonably be considered an agile practice. It might be important, but it’s something other than agile.
In the next section of the book, we examine the core agile practices in action and show how to combine them with ICONIX Process, itself a core subset of UML modeling techniques. This won’t be a theoretical discussion, but a very practical example: a real-life C#/.NET application.

Agile ICONIX Process in Practice: The Mapplet Project

Frontmatter
Chapter 5. Introducing the Mapplet Project
Summary
In this chapter, we introduced the ESRI mapplet project, a Professional Services project being run at ESRI using their ArcGIS Server mapping software and ICONIX modeling to define the product in terms of use cases. We also showed the initial rough draft of requirements and the use case model for this project, and we spent some time upfront creating a domain model. The domain model provides a project glossary, so that all subsequent artifacts (use cases, design models, etc.) can be written using consistent names. We also gave an overview of the ArcGIS Server platform and indicated which parts of its APIs the mapplet will use.
For the rest of Part 2, we’ll continue to follow the mapplet project and show how the team got from use cases to code over the first two successive releases.
Chapter 6. Modeling the Mapplet (Release 1)
Summary
In this chapter, we told the story of a project team beginning to adapt to ICONIX Process, with the prototype release of the mapplet project. We showed how the initial set of use cases was analyzed and broken down into an objectoriented design using a cookbook-style, step-by-step process.
This first release was intended as a way of testing ESRI’s new server product, so release 1 was earmarked very much as a prototype. While the team did do some modeling, the emphasis was on writing prototype code and getting familiar with the new technology. As a result, the team skipped some of the initial design efforts. However, to the team’s credit, the deliverable software for this first release matched up to the requirements pretty well.
We also showed one of the safety nets (namely, code-level refactoring) that Agile ICONIX puts in place for when the team strays from the process path. (This does occur, particularly early in a project when the team is still adapting to the new design process, so expect it to happen and be prepared!)
Finally, we saw the end result of this first release: the alpha release of the mapplet.
Having seen the first release, the team now has a much better idea of what works and what doesn’t, designwise. So in the next chapter, we revisit the design and give it a serious going-over in preparation for release 2.
Chapter 7. Synchronizing the Model and Code: One Small Release at a Time
Chapter 8. Mapplet Release 2
Summary
In this chapter we began (and concluded) the second release of the mapplet project. We extended the use case diagram that we used for release 1 and produced a plan so that we know what we need to deliver for this release. We also took the use case analysis that we did for release 2 and used it to create a detailed design.
We introduced an extension to ICONIX Process called persona analysis, for designing the product around a core set of target users. The use of persona analysis also means that we can take advantage of additional interaction design techniques. We’ll revisit this technique in much more detail in Chapter 10.
Finally, we looked at the source code for release 2, refactored a few minor points here and there, and then basked in the glow of the screenshots from the finished product. Party on!

Extensions to ICONIX Process

Frontmatter
Chapter 9. Agile Planning
Chapter 10. Persona Analysis
Summary
Persona analysis provides a compelling method of focusing the requirements for any new product. The technique works best when it’s applied early in the project life cycle, because it tends to drive the requirements. On the mapplet project, the technique was applied early in release 2 (the first release being a prototype), and the result was that some useful requirements were identified that might otherwise have been missed.
Interaction design isn’t just about designing the “look” of a user interface. It’s also about designing the behavior—determining how the UI will behave and respond to user inputs. This is why interaction design and use cases work so well together, especially when combined with personas.
Chapter 11. A “Vanilla” Test-Driven Development Example
Summary
In this chapter, we walked through a practical example of TDD in action. Although TDD is often accompanied with a small amount of up-front UML diagramming, we deliberately avoided that in the example. This was to contrast the techniques used to create a design using vanilla TDD with the techniques used to create a design using up-front UML diagramming.
In the next chapter, we hit the Rewind button and repeat the example using TDD plus some up-front analysis and design (A&D). Naturally, we use ICONIX Process as the A&D methodology.
Chapter 12. Test-Driven Development with ICONIX Process
Summary
In this chapter, we examined how ICONIX Process and TDD can be combined to great effect. To combine these two disciplines, we have had to rewrite the rules slightly for TDD, but the basics are pretty much the same.
Using TDD on its own without any up-front design modeling is actually very rare. Even in XP a certain amount of up-front design modeling is generally used—this is normally a collaborative design workshop held just before the coding session, also known as Just-in Time (JIT) Design.4 In such environments, consider using ICONIX Process as described here to improve the collaborative design process.
Finally, at the end of the chapter, we described an automated, model-driven testing process that you can use to drive a testing effort from your use case-driven models.
Backmatter
Metadaten
Titel
Agile Development with ICONIX Process
verfasst von
Doug Rosenberg
Matt Stephens
Mark Collins-Cope
Copyright-Jahr
2005
Verlag
A-Press
Electronic ISBN
978-1-4302-0009-3
Print ISBN
978-1-59059-464-3
DOI
https://doi.org/10.1007/978-1-4302-0009-3

Premium Partner

    Bildnachweise