**One good choice use systems development with MDA - Model Driven Architecture**

The system development lifecycle process is a problem-solving process where requirements maybe considered problems occurring within a domain, systems that address the requirements may be considered solutions residing within an environment, and problem solving involves understanding a problem, solving the problem, and implementing the solution.

One choice to solving problem of process of development is using MDA as good choice and with development tools integrate. Can implement with languages as Java, Python, C++.

Every system development lifecycle process involves the following types of lifecycle activities:

- Requirements gathering activities to capture requirements that define what a system should do. This results in a requirements model that describes the problem and what a solution entails, and is said to occur from a conceptualization perspective since it focuses on the problem.
- Analysis activities to understand the requirements. This results in an analysis model that describes how an abstract or implementation-independent solution satisfies what is specified by the requirements model, and is said to occur from a specification perspective since it focuses on the problem and solution.
- Design activities to determine how a system will satisfy its requirements. This results in a design model that describes how a real or implementation-specific solution satisfies what is specified by the analysis model, and is said to occur from a specification perspective since it focuses on the problem and solution.
- Implementation activities to build a system. This results in an implementation model that describes the actual solution or physical system that satisfies what is specified by the design model, and is said to occur from an implementation or realization perspective since focuses on the solution.
- Testing activities to verify that a system satisfies its requirements.
- Deployment activities to make the system available to its users.

Furthermore, there are many types of approaches or lifecycle models, bellow :

1. Iterative,

2. Waterfall,

3. And so forth

Applying these activities, however every approach must confront the forces of change and complexity.

1. Iterative,

2. Waterfall,

3. And so forth

Applying these activities, however every approach must confront the forces of change and complexity.

Figure 1 shows a conceptual view of the system development lifecycle process.

The domain and environment are shown as circles. The problem and solution are shown as solid-outline rectangles within the circles. The problem-solving process is shown as a solid-line path from the problem to the solution, and each perspective is shown as a dashed-line path from the solid-line path to the activities related to that perspective. Activities are shown as a shape with a straight top and bottom and convex arcs on the two sides, and models are shown as solid-outline rectangles.

When an activity uses a model as input, a dashed arrow is shown from the model to the activity. When an activity produces or updates a model as output, a dashed arrow is shown from the activity to the model. Because the requirements model represents the problem and the implementation model represents the solution, a dashed arrow is shown from each model to the item it represents...

The domain and environment are shown as circles. The problem and solution are shown as solid-outline rectangles within the circles. The problem-solving process is shown as a solid-line path from the problem to the solution, and each perspective is shown as a dashed-line path from the solid-line path to the activities related to that perspective. Activities are shown as a shape with a straight top and bottom and convex arcs on the two sides, and models are shown as solid-outline rectangles.

When an activity uses a model as input, a dashed arrow is shown from the model to the activity. When an activity produces or updates a model as output, a dashed arrow is shown from the activity to the model. Because the requirements model represents the problem and the implementation model represents the solution, a dashed arrow is shown from each model to the item it represents...

## No comments:

Post a Comment