-Figure shows very clear boundaries between each activity. In practice, the boundaries are not so clear. Sometimes it is difficult to say if a particular activity belongs in one box or another. The precise boundaries are not important.
-What is important is to understand the relationships between these activities. Earlier activities, such as defining requirements and object-oriented analysis, determine the course of activities that follow them, such as defining essential use cases or object-oriented design. However, in the course of those later activities, deficiencies in the products of earlier activities emerge. For example, in the course of defining a use case, an ambiguous or conflicting requirement may become apparent. It may be necessary to modify existing use cases or to write new ones. You must expect such iterations.
As long as the trend is for later iterations to produce fewer changes than earlier iterations, consider them part of the normal development process. Following are brief descriptions of some of the activities shown in the above figure. These descriptions provide only enough information to explain how the patterns discussed in this work apply to a relevant activity. Business planning. This typically starts with a proposal to build or modify a piece of software. The proposal evolves into a business case. A business case is a document that describes the pros and cons of the software project and includes estimates of the resources required to complete the project. If a decision is made to proceed with the project, then a preliminary schedule and budget are prepared.
Define requirements. The purpose of this activity is to produce a requirements specification that says what the software produced by the project will and will not do. This typically begins with goals and high-level requirements from the business case. Additional requirements are obtained from appropriate sources to produce an initial requirements specification.
Build Business planning: business case, budget
Detailed planning
Usability testing
Object-oriented analysis: low-level essential use cases, conceptual model, sequence diagrams
Design user interface
Object-oriented design: class diagrams, collaboration diagrams, state diagrams
Logical database design
Write documentation
help
Define requirements: requirements specification
Define high-level essential use cases
Create prototype Define high-level system architecture
Coding Physical database design
Testing
Deployment
As the requirements specification is used in subsequent activities, necessary refinements to the requirements are discovered. The refinements are incorporated into the requirements specification. The products of subsequent activities are then modified to reflect the changes to the requirements specification.
Define essential use cases. A use case describes the sequence of events that occurs in a specific circumstance between a system and other entities. The other entities are called actors. Developing. Usecases improves our understanding of the requirements, analysis, or design on which the use case is based. As we develop a better understanding of requirements, analysis, and design, we are able to refine them. Essential use cases describe events in terms of the problem domain. Use cases that describe events in terms of the internal organization of software are called real uses cases.
The use cases most appropriate for refining requirements are high-level essential use cases. They are high level in that they explore the implications on which they are based on, but they do not try to add additional details. Create prototype. Create a prototype of the proposed software.
A prototype can be used to get reactions to a proposed project. Reactions to a prototype can be used to refine requirements and essential use cases.
Define high-level system architecture. Determine the major components of the system that are obvious from the original proposal.
Also, determine their relationships. Object-oriented analysis. The purpose of this activity is to understand what the software produced by the project will do and how it will interact with other entities in its environment.
The goal of analysis is to create a model of what the software is going to do, but not how to do it. The products of object oriented analysis model the situation in which the software will operate from the perspective of an outside observer.
The analysis does not concern itself with what goes on inside the software.
Object-oriented design. The purpose of this activity is to determine the internal organization of the software. The products of the design effort identify the classes that will comprise the internal
logic of the software. They also determine the internal structure of the classes and their interrelationships.
Coding. The purpose of this activity is to write the code that will make the software work.
Testing. The purpose of this phase is to ensure that the software works as expected.