Describe the Components making up a Software Development Methodology

A software development methodology consists of two complementary components:

1. a standard process and
2. a standard notation .

The standard process is the sequence of tasks and decisions that moves the project from inception to completion. A software development notation is the form of communication used to document the knowledge and the decisions accumulated as products of the overall process.

There is no standard software development process. The process that you will use in this course is a generalization of the common elements of the leading software development methodologies. If you understand these essential elements, you will be able to customize the application of the general methodology to your specific domain or even choose one of the current methodologies that best supports your needs.
Theseries of images below names and describes the phases making up a the project life cycle for developing software:

Regardless of the names used for the life-cycle phases, all the methodologies have at least one concept in common.
Object-oriented software development is best accomplished with an iterative process. Each iteration or single pass through one or more steps in the process adds more information and/or features. Continued iteration extends and refines the model until all the desired features have been added and all requirements have been satisfied. Iterative and Incremental development is any combination of both iterative design or iterative method and incremental build model for software development. The combination is of long standing and has been widely suggested for large development efforts. During software development, more than one iteration of the software development cycle may be in progress at the same time. and "This process may be described as an 'evolutionary acquisition' or 'incremental build' approach." The relationship between iterations and increments is determined by the overall software development methodology and software development process. The exact number and nature of the particular incremental builds and what is iterated will be specific to each individual development effort.

People at different levels of the organization will have different viewpoints on the system, so it is important to include both managers who manage the processes and staff who actually perform the processes to gain both high-level and low-level perspectives on an issue. Also, the kinds of interview subjects that you need may change over time. For example, at the start of the project the analyst has a limited understanding of the as-is business process. It is common to begin by interviewing one or two senior managers to get a strategic view and then move to mid-level managers who can provide broad, overarching information about the business process and the expected role of the system being developed. Once the analyst has a good understanding of the big picture, lower-level managers and staff members can fill in the exact details of how the process works. Like most other things about systems analysis, this is an iterative process, which starts with senior managers, moving to midlevel managers, then staff members, back to mid-level managers, and so on, depending upon what information is needed along the way.
Given many possible activities from requirements through to implementation, how should a developer or team proceed? Requirements analysis and OOA/D needs to be presented in the context of some development process. In this case, the well-known Unified Process is used as the sample iterative development process within which these topics are introduced. However, the analysis and design topics that are covered are common to many approaches, and learning them in the context of the Unified Process does not invalidate their applicability to other methods.
Iterative development is a skillful approach to software development, and lies at the heart of how OOA/D is presented in this book. The Unified Process is an example iterative process for projects using OOA/D, and it shapes the book's presentation. Consequently, it is useful to read this chapter so that these core concepts and their influence on the book's structure are clear.

The Unified Modeling Language (UML) defines a standard for the notation used to describe the products of object-oriented software development. The UML does not define a process for developing these products, however. It is a form of communication used to document the knowledge and the decisions accumulated as products of the overall software development process.