Analysis Through Pictures


This section of the site contains a textual (supported with diagrams) description of the complete process that is described within the PowerPoint presentations. To keep the pages down to a sensible size, each Chapter has its own page.
Foreword I have been reading books about analysis and taking analysis training classes, since 1988. These include books by Tom DeMarco, Ward and Mellor, Yourdon and of course the Unified Software Development Process by the Three Amigos. I have also taken structured analysis training from several experts in the field, but only one book has left me with a sense that I learned a process along with the notation. That is; Object Lifecycles (Modeling the world in states) by Sally Shlaer and Stephen Mellor. This book was published in the late 1980s. Other books on requirements, to cite a common analogy; describe the details of the trees, bushes and undergrowth, but have always left me with a sense that I had no picture of what the wood looks like. That is to say that they describe analysis diagrams and best practices for creating them, but left me without the knowledge of ‘how to I use these on my current project?’ You will find that much of this material is based upon Sally and Stephen’s work, but since their book was published before the worldwide adoption of use cases, much of this material is also outside of the scope of their book, and based on my own experiences. Personal History My career ambitions have been aimed at software development from an early age. I remember visiting a local government computer establishment when I was around 9, and being fascinated with the machinery, the tape drives, the disk-drives and having to wear hair nets, a plastic coat and coverings over my shoes. I was hooked and would jump at any opportunity to see a working computer. My first chance to study these fascinating machines came at the age of 14, when my school introduced ‘Computer Studies’ as a new student course. (I like to believe that I was first in line to sign up.) My development path through learning computers started with writing pseudo assembler code onto programming sheets, then coding BASIC onto punch cards. When I left school I had been allowed to enter commands to a remote computer directly through a teletype, and get an almost immediate response (sometimes within seconds). When I graduated I worked at a school that wanted me to teach Mathematics, but allowed me to also teach Computer Science as a secondary subject. It was here that I had my first access to a PC, the Commodore Pet. The vast majority of my early programming experience was with assembler, using a direct terminal or sometimes punched tape and other times by entering the machine code directly into memory via a series of switches. After 5 years of programming, I took a job write requirements documentation from which external subcontractors would develop the code. This was my first experience with requirements analysis and the first time that I needed to understand a ‘real’ SDLC[1]. From there my job title became aerospace Systems Analyst and this has driven my career ever since. While working in aerospace I was subjected to various development notations, from structured analysis, (Yourdon, DeMarco, etc) to object object-orientd analysis (Shlaer/Mellor, Booch and Rumbaugh). Eventually UML came along and all the other notations were dropped in favor of this unified language coming out of Rational. [Well, almost all – it was through my knowledge of Shlaer/Mellor that I moved from Aerospace into Telecommunications.] Once the aerospace funding shriveled up, I found myself leaving the relative safety of aerospace and moved into the big, bad, scary world of commercial enterprise. My interests in RUP and Business Analysis have come about from working with commercial enterprise systems. After reading books on RUP, and studying the application (that is now supplied by IBM), I decided that the process needed to be described in a sequential manner with actual steps that an analyst and project manager could follow. RUP describes a very heavyweight development process. In fact it is so bloated that no company could attempt to implement every detail of the process and remain successful for long. RUP is based upon the UML notation, and UML is similar to RUP, in that its notation is built upon all kinds of development efforts from different environments, and attempts to standardize the these notations. Similarly, no development process would sensibly attempt to employ all of the notation and diagram types described within UML. I decided that what was needed, is a SDLC that is based upon the best practices of RUP, utilizing only the minimal set of diagrams and notation provided by UML, that are specific to requirements analysts and could also be applied to all software development efforts that I have encountered in both my aerospace and commercial experience.. With plenty of free-time at my disposal, I am taking advantage of my situation to document that software development process. This book is the result work. Exercises No technical work should be complete without including some exercises; enabling the reader to test their knowledge of the preceding material. There are no explicit exercises in the following work, but it is left up to the reader to discover the mistakes, (or improvements) that can be found in the following examples. This work was performed using tools that had little checking of correctness capabilities. (Also consider that since many of the guidelines are unique to this work, there are no expectation that any tool at my disposal will be able to detect all of the errors.) At the end of each chapter , the reader is encouraged to review the chapter examples in an attempt to discover ways in which each may be improved[2]. All examples are available in electronic form, upon request. [1] By ‘real’ I mean that we defined the process and required documents prior to writing and debugging the code [2] And it the reader would like to send their findings in an email to lmunday@gmail.com, the author would be very grateful.

This section of the site contains a textual (supported with diagrams) description of the complete process that is described within the PowerPoint presentations.

To keep the pages down to a sensible size, each Chapter has its own page.

Foreword

I have been reading books about analysis and taking analysis training classes, since 1988. These include books by Tom DeMarco, Ward and Mellor, Yourdon and of course the Unified Software Development Process by the Three Amigos. I have also taken structured analysis training from several experts in the field, but only one book has left me with a sense that I learned a process along with the notation. That is;

Object Lifecycles (Modeling the world in states) by Sally Shlaer and Stephen Mellor.

This book was published in the late 1980s. Other books on requirements, to cite a common analogy; describe the details of the trees, bushes and undergrowth, but have always left me with a sense that I had no picture of what the wood looks like. That is to say that they describe analysis diagrams and best practices for creating them, but left me without the knowledge of ‘how to I use these on my current project?’

You will find that much of this material is based upon Sally and Stephen’s work, but since their book was published before the worldwide adoption of use cases, much of this material is also outside of the scope of their book, and based on my own experiences.

Personal History

My career ambitions have been aimed at software development from an early age.

I remember visiting a local government computer establishment when I was around 9, and being fascinated with the machinery, the tape drives, the disk-drives and having to wear hair nets, a plastic coat and coverings over my shoes. I was hooked and would jump at any opportunity to see a working computer.

My first chance to study these fascinating machines came at the age of 14, when my school introduced ‘Computer Studies’ as a new student course. (I like to believe that I was first in line to sign up.) My development path through learning computers started with writing pseudo assembler code onto programming sheets, then coding BASIC onto punch cards. When I left school I had been allowed to enter commands to a remote computer directly through a teletype, and get an almost immediate response (sometimes within seconds).

When I graduated I worked at a school that wanted me to teach Mathematics, but allowed me to also teach Computer Science as a secondary subject. It was here that I had my first access to a PC, the Commodore Pet.

The vast majority of my early programming experience was with assembler, using a direct terminal or sometimes punched tape and other times by entering the machine code directly into memory via a series of switches.

After 5 years of programming, I took a job write requirements documentation from which external subcontractors would develop the code. This was my first experience with requirements analysis and the first time that I needed to understand a ‘real’ SDLC[1].

From there my job title became aerospace Systems Analyst and this has driven my career ever since. While working in aerospace I was subjected to various development notations, from structured analysis, (Yourdon, DeMarco, etc) to object object-orientd analysis (Shlaer/Mellor, Booch and Rumbaugh). Eventually UML came along and all the other notations were dropped in favor of this unified language coming out of Rational.

[Well, almost all – it was through my knowledge of Shlaer/Mellor that I moved from Aerospace into Telecommunications.]

Once the aerospace funding shriveled up, I found myself leaving the relative safety of aerospace and moved into the big, bad, scary world of commercial enterprise. My interests in RUP and Business Analysis have come about from working with commercial enterprise systems.

After reading books on RUP, and studying the application (that is now supplied by IBM), I decided that the process needed to be described in a sequential manner with actual steps that an analyst and project manager could follow. RUP describes a very heavyweight development process. In fact it is so bloated that no company could attempt to implement every detail of the process and remain successful for long. RUP is based upon the UML notation, and UML is similar to RUP, in that its notation is built upon all kinds of development efforts from different environments, and attempts to standardize the these notations. Similarly, no development process would sensibly attempt to employ all of the notation and diagram types described within UML.

I decided that what was needed, is a SDLC that is based upon the best practices of RUP, utilizing only the minimal set of diagrams and notation provided by UML, that are specific to requirements analysts and could also be applied to all software development efforts that I have encountered in both my aerospace and commercial experience..

With plenty of free-time at my disposal, I am taking advantage of my situation to document that software development process. This book is the result work.

Exercises

No technical work should be complete without including some exercises; enabling the reader to test their knowledge of the preceding material.

There are no explicit exercises in the following work, but it is left up to the reader to discover the mistakes, (or improvements) that can be found in the following examples. This work was performed using tools that had little checking of correctness capabilities. (Also consider that since many of the guidelines are unique to this work, there are no expectation that any tool at my disposal will be able to detect all of the errors.)

At the end of each chapter , the reader is encouraged to review the chapter examples in an attempt to discover ways in which each may be improved[2].

All examples are available in electronic form, upon request.

[1] By ‘real’ I mean that we defined the process and required documents prior to writing and debugging the code

[2] And it the reader would like to send their findings in an email to lmunday@gmail.com, the author would be very grateful.

Introduction

This work describes a requirements lifecycle based on the Rational Unified Process (RUP) framework^{^[1]}, from business modeling through to analysis and design.

The RUP is a framework, not a development method. It contains many, if not most, of the best practices for software development. It describes the Software Development Life Cycle (SDLC) in terms of Actors, Artifacts and Activities. These are grouped into 9 disciplines (some included in multiple disciplines). There are approximately 30 actors, around 100 artifacts and even more activities described by RUP in total. No SDLC could adopt the whole framework and expect to accomplish an efficient method for developing software.

RUP uses the Unified Modeling Language (UML) as its basis for artifact development. Like RUP, UML contains every notation that every developer could need for modeling within a SDLC. No development effort would utilize the complete UML notation. In fact UML has many more redundancies that RUP, some of them duplicates and some just do not work together.

With all these tools available for software development, how does one sift through them all and pull out a subset that is appropriate for their particular situation?

This work describes a subset of RUP and UML, that when combined together prove an effective method for software development in almost any situation. It makes use of the most useful development practices and the most common UML notations, but only to the extent that these activities and notation are sufficient without any duplication or ambiguity. I.e. it describes a minimum set of tools that any software analyst needs, while at the same time allowing the analysis of just about any type of development project involving computer systems.

Purpose

The purpose of this work is to describe an implementable use case based approach for developing the requirements for a project. It is not going to describe requirements artifacts and then not explain their purpose or where they fit into the project lifecycle[2]. Every artifact that is described is the result of a step in the process that produces something for a specific stakeholder.

Other software development processes may provide a framework for working with application requirements, but are rarely specific about the actual steps that an analyst could follow in order to produce a complete set of requirements artifacts. This process specifies the exact steps that the analyst could follow, with examples, and the format of the artifacts that are produced from those steps.

The examples are based upon real-world commercial business systems and the result of the process is a complete^{^[3]} analysis model of a computer system.

Audience

This document is written for requirements analysts and systems or business/systems analysts who are looking for a specific set of requirements development processes that will work for them in order to deliver an appropriate analysis model. In particular, users of the RUP framework who would like a customized their process to follow the best practices of the RUP[4].

What this work does not include:

· The purpose of use cases and how they are used by the business or an IT department.

The reader is expected to be experienced extracting requirements from stakeholders and documenting these details with use cases. It helps if the reader has a basic understanding of the difference between a business use case and a system (or application) use case.

· Class diagrams and normalizing entity relationship diagrams

The reader should have experience with entity relationship modeling, and have a basic understanding of class attributes and operations. It also helps to understand class relationships, such as aggregation, composition and inheritance.

· Managing a Software Development Life Cycle

The work in this book should be able to be incorporated into most SDLCs that employ requirements analysis. It does not discuss the activities of a project or program manager.

· Notation

This work is not intended to make recommendations about specific notation used within the UML diagrams. Whether using underscores, capitalized words or Hungarian notation, etc, is normally defined by development standards. The only recommendation is that the notations on the diagrams should be consistent. For example, If using capitalized words to describe classes, than whenever a class is referenced, the name in the reference should also be capitalized.

Scope

The material starts with some practices for working with MS Office in a requirements environment. It then goes on to give an overview of the ideas behind the work; talks about use cases; describes a process for developing use case models; project glossaries; the lifecycle of a use case; use case storyboards; a process for object-oriented analysis and modeling the world in states.

The work is in 2 parts:

· The first part is a series of best practices for working with requirements, tools and use cases.

· The second part uses the best practices to model a restaurant management system from a business vision through to a complete set of software requirements.

The process is neither Waterfall, nor Agile. Being use case based it may be deployed in either environment. The description of the process is sequential, that is it starts with the business vision, and walks you through the steps to produce a set of software requirements, but there is no reason why all steps need to be completed in sequence.

To adopt the process in an iterative SLDC, one simply walks each use case through the complete process in turn.

To adopt the process into a waterfall SDLC, one simply develops the complete set of use cases, and adds the required documents and gates at the appropriate places in the process.

This process is mainly concerned with the processes and artifacts that an Analyst is interested in. Project management guidelines can be added at the appropriate places.

Definitions, Acronyms, and Abbreviations

See Appendix A for a complete list of technical terms used within this text.

Some terms that are useful in understanding the overall material are:

The differences between Project, Product and Program. In this document they are used as follows:

Project – is a development effort that satisfies the needs of the business. A project may encompass several business areas, each with their own specific needs. These needs are implemented by one or more enterprise-wide systems.

Product – is an application or series of applications that reside on a system. A single project may impact several products.

Program – is the complete set of products that are impacted by a project.

Therefore; a Project Manager is responsible for the overall success of a project to the business. A program manger is responsible for the successful implementation of a project. Whereas a product manager is responsible for all project implementations that impact the applications under their responsibility.

In addition you will need to understand how this book differentiates between a system and an application.

Application – is the software that satisfies a business[5] need.

System – is the hardware and software that automates a process or processes that satisfy business needs.

A system may contain several applications, but a software application can only reside within 1 system[6].

^{^[1]} IBM Rational will tell you that no-one in their right mind should attempt to use every recommendation within the RUP on a single project. Nor does RUP encompass all the needs of most projects. Customization is always necessary.

[2] This is a common problem I have experienced with software modeling books. Lots of examples, but no guidelines as to how to fit the examples together in a full SDLC.

^{^[3]} Complete as much as I can verify with MS Visio.

[4] RUP 2003 best practices; these have changed in later versions – not necessarily for the better, IMO.

[5] I include IT as a part of the business.

[6] This rule is important when it comes to building use cases – please make sure that you understand its implications.

Click here to display the book table of contents, as links to PDF files of each chapter .

Contents