3-The+SDLC

__ Tools of Modern Systems Analysis __ - When designing systems, a system analyst starts off by creating a model. By creating a model, an analyst can determine certain critical features in a system. Also if changes are necessary a model can easily be changed to fit the new required needs of the system. As another bonus, models are used for documentation purposes.
 * The Systems Development Life Cycle**

So the main reasons for using models is: 1. Focus on important system features while downplaying less important features. 2. Discuss changes and corrections to the user’s requirements with low cost and minimal risk. 3. Verify that the systems analyst correctly understands the user’s environment and has documented it in such a way that the systems designers and programmers can build the system. 4. Serve as documentation for new users, systems analysts, system developers etc to understand the system 5. Serve as documentation for future enhancements 6. Serve as documentation for system support after the system has been implemented

- There are many different types of models out there and each are used to model different aspects of a system.

__ Modeling System Functions: The Data Flow Diagram __
- **Data flow diagrams** are useful in modeling only one aspect of a system, its __functions__. - Data flow diagrams usually consist of processes, data flows, stores, and terminators, and can also include control flows, control processes, and control stores. The last three are useful for modeling real-time systems.

- Here is an [|example] of a typical Data Flow Diagram · **Processes** are shown as circles. They represent the various individual functions that the system carries out.

· **Flows** are shown by curved, directed arrows. They are the connections between the processes and represent the information that the processes require as input and/or the information they generate as output.

· **Data stores** are shown by two parallel lines, or by an ellipse. They show collections of data that the system must remember for a period of time. When the is finished, the stores will typically turn into files or databases.

· **Terminators** show the external entities with which the system communicates. Terminators are typically individuals, groups of people, external computer systems, and external organizations. - The data flow diagram provides a good overview of the systems functions, but does not given any detail beyond the order of operations. Thus to show which information is modified and how it is modified, two textual models are used, a data [|dictionary] and the [|process specification].

- Some complex systems can end up having multiple data flow diagrams, from two to several hundred.

Modeling S tored Data: The Entity-Relationship Diagram
- All systems store data about the environment in which they interact, and most modern day systems are quite complex.

- It is not enough to know what data is stored where, but analysts most also know what relationships there are between this data. Since Data Flow Diagrams do not show this, it takes another model type, the [|Entity-Relationship Diagram]

- The entity-relationship diagram consists of two major components: Object Types and Relationships · **Object types** are shown by a rectangular box on the entity-relationship diagram. An object type represents a collection, or set, or objects (things) in the real world whose members play a role in the system being developed, can be identified uniquely, and can be described by one or more facts (attributes).

· **Relationships** are shown by the diamond-shaped boxes on the diagram. A relationship represents a set of connections, or associations, between the object types connected by arrows to the relationship.

__ Modeling __ Time-Dependent Behavior__: The__ State-Transition __Diagram__
- In most systems, the sequence of in which data is accessed and certain functions are performed are trivial. However this is an important aspect to on-line systems and real-time systems. Many real-time systems, for example, must respond within a very brief period of time, sometimes only a few microseconds, to certain inputs. - In order to map out these sequences, analysts use [|State-Transition Diagrams]. In this example it shows the behavior of a computer controlled washing machine.

· In this diagram, the rectangular boxes represent **states** that the system can be in. Each state represents a period of time during which the system exhibits some observable behavior. · The arrows connecting each rectangular box show the **state-change**, or transitions from one state to another. · Associated with each state-change are **conditions**, which are the events or circumstances that caused the change of state. · **Actions** are the response, output, or activity that takes place as part of the change of state.

__ Modeling __ Program Structure__: The__ Structure Chart
- All of these models represent a different part of the system and are usually created by the system analyst. Using these models, system designers sometimes create a [|Structure Chart] to help show the hierarchy of modules to implement the system requirements.

· Rectangular boxes represent **modules** (e.g., a C or Pascal procedure, a COBOL paragraph or subprogram). · The arrows connecting the boxes represent **module invocations** (e.g., subroutine calls or procedure calls). · The diagram also shows the input parameters passed to each module that is invoked, and the output parameters returned by the module when it finishes its task.

- The Structure Chart is rarely ever shown to the user, since it’s solely used for the implementation of a system and not its use.

-All organizations have systems development projects, yet the methods used to complete these tasks vary widely depending on the size of the organization. A set method (also known as a project life cycle) is implemented in organizations for the following reasons:  -     It outlines the necessary tasks that need to be performed in a systems development project  -     It provides homogony throughout the entire organization regarding the coordination of various systems development projects.  -     It gives management the ability to constantly see the progress of the systems development project so they can reevaluate the worthiness of said project. [|The Classical Project Life Cycle] __** - The classical project life cycle is characterized by two distinctive features which distinguish it from an ordinary project life cycle. This includes a strong emphasis on bottom-up implementation as well sequential progression from one stage to the next stage. //__ The classical project life cycle has some major flaws though:  __// -Due to its implementation process the project is of little or no use until the very end, as that is when all the different parts of the system are joined. If something goes wrong in the middle of the project, everything is delayed. -Also because of Its emphasis on bottom-up implementation, many of the more serious bugs aren’t detected until later on during the project, while small bugs are caught at the beginning. -Because of the long time it takes to complete a project using the classical project life cycle, the project may be outdated or irrelevant by the time of its completion because of changing circumstances. [|The Semi Structured Project Life Cycle] __** ** - ** The semi structured project life cycle differs from the classical project life cycle in a few important ways: - Instead of using bottom-up implementation, the semi structured project life cycle uses top-down implementation, meaning that the most complex/important aspects are tested first, as to catch the more serious system defects. - This project cycle also increases the feedback between the implementation process and the analysis process. -Additionally, this project life cycle uses structured design as opposed to classical design.
 * __ The Project Life Cycle __**
 * __
 * __
 * __

[|The Structured Project Life Cycle] __** The structured project life cycle consists of nine activities:  1. ** Survey ** - This step of the cycle generally includes discovering who the users of the system are and what are the deficiencies of the current system. 2.   ** ** Systems Analysis- ** This phase typically involves the merging of the user’s environment and project charter into a model. 3.   ** ** Design- ** It is during this stage that the tasks of the specification are allocated to different processors to perform said tasks. It is also during this phase that the human implementation model is developed. This model concentrates on the human/computer interaction aspects of the system. 4.   ** ** Implementation- ** This stage involves the coding and integration of modules, which help to create a firm backbone for the system. This phase also utilizes the top-down implementation and structured programming. 5.   ** ** Acceptance Test Generation ** - As all of the information from the structured specification is now complete, the system may be evaluated from the users perspective by setting up acceptance test cases. 6.   ** ** Quality Assurance- ** Using the data generated from the “acceptance test generation,” this phase is the final testing phase and can test the completely integrated system. 7.   ** ** Procedure Description- ** This part of the cycle basically instructs the users of the system how to effectively use the automated parts of the system. 8.   ** ** Database Conversion- ** Although the significance of this task varies with each project, it involves converting the former database(s) to the new system. 9.   ** ** Installation- ** This stage varies with each project, with some systems switching over overnight, while other projects are more gradual with their switch to the new system. __**Radical vs. Top-Down Implementation**__ - The project manager must decide on the approach that his/her team will take, usually picking a moderated mix between the two. This depends on several factors including the preferences of the user, amount of available time, consequences of mistakes, and monetary constraints. -The radical approach is most used for projects where the design might possibly change or is incomplete, while a more conservative choice may be necessary if the project is large, involving a lot of time, money and planning. -While the prototyping life cycle is quite similar to the radical top-down approach mentioned earlier, this project life cycle assumes that a paper model of the system will eventually be created. It is also assumed that after the working model is completely setup, that a real production system will be implemented to take over. This is necessary because the prototype is unable to handle real system requirements. -The prototyping life cycle is used only as a preliminary model, not as a functional system. -The paper model that is made for the prototyping life cycle can be used to help facilitate maintenance repairs or it may even help for developing a replacement system. It is necessary to keep the paper model because without it system maintenance/replacement would be very difficult. -This life cycle is used when the user is not completely sure what he/she wants or he/she wants to experiment with different approaches.
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * -**The radical approach in the most extreme sense means that all activities are performed parallel, or at the same time, while on the conservative approach requires that every task be completed before the next one can begin.
 * __ [|The Prototyping Life Cycle] __**