|
In Chapter 1, “Together – The Difference It Makes” we talk about why Together is an exciting technology. We are not interested in the marketing flannel here. Together does something different from other development platforms, and that opens up new possibilities. We want to look into what this is and why it can make a significant difference to the performance of small teams. Also in Chapter 1 we introduce four foundational themes that run through most of the other chapters –
- maintaining just one single-source model
- the minimum metamodel
- the perturbation change model
- continuous measurement of quality.
Maintaining just one single-source model is based on the idea that information about the system should be stored in only one place and maintained only once, even though it is viewed and modified in many different forms.
The minimum meta-model is a view of the essential elements in any development process that need to be defined and effectively cross-referenced – in summary these are the requirements, the tests, the design and the implementation code.
The perturbation change model is a way of looking at the development process in terms of moving from one valid state (or build) to the next in small iterative steps. This is not a different development process but a way of looking at most iterative evolutionary development processes.
Continuous measurement of quality is a necessary requirement for iterative evolutionary lifecycles, that put different stresses on the development activities and tools environment compared to waterfall-style lifecycles.
After this introduction, what about the structure for the rest of the book? Many books are structured by each step in a development process from requirements to deployment, or by taking each UML diagram types in turn. But there are some snags with that approach. Firstly, it is hard to relate the diagram types to a software development process – many diagrams are touched at different points in the software development process and with a different emphasis at each point. Secondly, it’s artificial. Together invites you to develop your software in an organic and evolutionary way, and we wanted to write a book that invites you to read and explore similarly. And another pressing reason we decided against structuring the book by the different diagram types is because it would be rather dull – for you to read, and for us to write!
Then, we were posed an interesting question – “What’s the least that needs to be done to deliver and use software?” Well, if you have some software already (and there nearly always is some), the answer is to just deliver and use that software. You may do other steps before that, particularly if you want different or additional functionality or quality, but you must also deliver the software. Furthermore in looking for a common way of thinking about the development process for small teams this last step is also the starting point, since before you can add functionality to a system you must be sure it’s current functionality works.
So we decided that Chapter 2 should start here – the ‘last’ step. That chapter is called “The Last Step – Deploy and Run!”. We take the opportunity to introduce our example domain model that will be used for most of our illustrations. We also explore many of Together’s capabilities with a system that actually runs – a good way to learn. The best way to read this chapter is alongside your computer where you can access the software discussed at this book’s companion web site. If you have access to the web now, check it out at www.bettersoftwarefaster.com. By starting here we can also ensure that those of you using the book with this software are starting from a valid starting point – one where the existing code and the chosen development environment run correctly and the defined tests all pass.
In Chapter 3 “The First Step – Model the Domain”, we look at an important launching point for a new team. While this is also a good opportunity to discuss the essentials of the class diagram, the main emphasis is on how to build a model that will act as an effective interface between business experts who know the essence of the business and the vision for the new system and the software development team that must realize the vision. This model is also important as it defines the vocabulary for both requirements and implementation classes, and it links too to the definitions of persistent data and user interaction. This chapter uses object modeling in color [2] as defined by Peter Coad and others, which helps to bring the analysis patterns and domain-neutral models to life and enhance the readability of the models [Coa99].
Gaining a good understanding of the requirements is sometimes overlooked by small (and larger) teams in time-pressured projects, but this is a potentially project-fatal mistake. In Chapter 4, “The Stakeholder Step – Specify Requirement”, we discuss capturing specifications using UML, particularly the use case and activity diagrams. The diagrams are simple to understand, which is essential to make them effective at this level. But building effective requirements models is by no means easy and we discuss key issues to keep in mind, especially strategies for keeping the requirements simple and amenable to management in an agile iterative process that small teams need.
Chapter 5, “The Controlling Step – Feature-Centric Management” is an explanation of a planning, estimating and project control process that we recommend to small teams. Our interest here is to keep planning and management as simple and as transparent as possible. Again, the question posed before is relevant: “What is the least we need to do to deliver the software?” – that’s our goal. One key simplification introduced to improve the management of iterative lifecycles, is to merge the units of planning with the units of requirements, whether these are use cases or features. We refer to development processes that make this simplification as “feature-centric” – hence the title of this chapter.
Some might interpret the goal of seeking the least that is needed, as suggesting that we are looking for the line of least resistance, and inevitably the quality of the software will suffer. While this could be a danger it is certainly not our meaning nor our intention. Chapter 6, “The Continuous Step – Measure the Quality” looks at how to ensure that quality is maintained throughout the development process. Our book is called “Better Software Faster” to which the natural response is “Better than what?”. This chapter looks at the techniques for measuring quality continuously so that we can compare the quality of any software build against any other and thereby objectively assess whether or not it is better. By contrast many projects only measure quality with functional tests, and only carry this out late in the project. This is a serious mistake. We suggest a variety of ways in which the quality status of builds can be established, including testing, automated metrics, automated audits, document generation and inspection.
Chapter 7, “The Micro Step – Design and Implement” is a look at the work of software development day by day. It considers the tasks in taking one or more requirements and adding that functionality to the current build. We also look at the techniques you will employ using Together ControlCenter for designing the functional tests, the user interaction, the object interaction and persistent data, as well as documenting the code and links to the requirements. Elements of Together’s Interactive Development Environment (IDE), such as its editors, GUI-builder, debugger and source-code formatter are mentioned.
Chapter 8, “The Macro Step – Architecture” considers the system at a different scale and perspective. Many different definitions of ‘software architecture’ have been used since the phrase was first coined, reputedly by F. P. Brooks. For us architecture means the principle divisions of the software and the policies and patterns used to extend the software. In small teams, architecture is not the job of a separate team, and for this reason some teams simply let it evolve. We believe though that architecture is too important, even in small projects not to be given separate consideration. In this chapter we look at how the requirements for architecture are derived from non-functional or “level of service” requirements. This chapter also gives us an opportunity to consider how the package diagram, with Together’s dependency analysis, is a key weapon in the software architect’s armory and how component and deployment diagrams also help.
Chapter 9, “The J2EE architecture” looks at the specifics of architectures based on Sun’s J2EE standard and how Together ControlCenter provides support for this. We also talk briefly about our favorite technique for mapping objects to databases.
Finally Chapter 10, Parting Words, gives us an opportunity for a brief reflection on the scope and limitations of this volume.
Throughout the book we’ll show you how to get the most out of Together, whatever formal process (or lack of it) you may have adopted. For example, we’ll be exploiting Together’s open API – an extensive Java-based API that constitutes a comprehensive plug-in architecture for Together – to develop modules to make development and documentation easier. We hope it will encourage you to explore this powerful and flexible facility in Together ControlCenter. Together is after all a development platform rather than a development tool. As teams discover specific tools, patterns, audits or integrations they need, but which are not yet delivered “out of the box”, the open API is the obvious place to turn.
And that’s it. We’re enthusiastic about Together, and we hope it comes across. If you’re as enthusiastic by the time you finish the book and have explored its accompanying software, then we’ll be happy. If it gives you a different perspective on how to build software in an efficient and quality-focused manner, we will have achieved our goal. |
