System Analysis and Design

System Analysis and Design

Object-oriented analysis and design (OOAD) is a popular technical approach for analyzing and designing an application, system, or business by applying object-oriented programming, as well as using visual modeling throughout the development life cycles to foster better stakeholder communication and product quality.

The purpose of any analysis activity in the software life-cycle is to create a model of the system’s functional requirements that is independent of implementation constraints.

Overview of Object-Oriented SA and Design

The software life cycle is typically divided up into stages going from abstract descriptions of the problem to designs then to code and testing and finally to deployment. The earliest stages of this process are analysis and design. The analysis phase is also often called “requirements acquisition”.

In some approaches to software development—known collectively as waterfall models—the boundaries between each stage are meant to be fairly rigid and sequential. The term “waterfall” was coined for such methodologies to signify that progress went sequentially in one direction only, i.e., once analysis was complete then and only then was design begun and it was rare (and considered a source of error) when a design issue required a change in the analysis model or when a coding issue required a change in design.

Task of Object-Oriented System Analysis (OOSA) (1 of 3)

Within OOSA there are 5 objects that must be identified and each object should be prioritized:

Objects within OOSA are:

Roles = are divided up between team members, investors and outside agencies of a project. Roles should be clearly defined prior to any project beginning.

Tangible things = is the end product that is produced usually for the customer. (Cell phone, car, house, etc..)

Interactions = may be the day-to-day meetings before work begins or monthly/quarterly meetings to discuss high/low level priorities. Interactions may occur at any level between within team members, investors and outside agencies.

Incidents = are those events or incidents that happen during the project that may affect the projects timeline. Incidents should be ranked so everyone knows what level of management should know of the incident. An example would be someone getting hurt on the job should be ranked as a “Incident Level-1”.

Specifications details = are considered to be critical particulars. The details may range in specifications of a product or coding of a particular software.

Task of Object-Oriented System Analysis (2 of 3)

Organize the objects: Once the objects have been identified, then they must be organized in a manner that best suite the projects needs.

Describe how the objects interact: The interaction of a product may be when a user performs certain functions or features on a software platform that generates a desired outcome.

Define the behavior of the objects: The behavior is the respective goal of the end users that is generated over a period of time by the product. An example would be artificial intelligent (AI).

Define the internals of the objects: The internal objects can be described as how the object is trigged or reacts to an event.

Iterative Development

Iterative development allows for the development team to complete various stages of the work in parallel.

This is the standard method of development for Object-Oriented Systems Analysis.

Waterfall Development

Waterfall is a sequential development model that requires the development

team completing the previous phase prior to work on the next phase beginning.

“open closed principle

How does OOSA & Design facilitate the enhance/development of systems (1 slide)

Pros and Cons of OOSA & Design 1 of 2

Pros and Cons of OOSA & Design 2 of 2

Object-oriented modeling 1 slide

Conclusion


Comments are closed.