Chapter 1 - Summary Systems analysis and design PDF

Preview

Summary

Chapter 1 Summary...

Description

Information system a set of interrelated components that collect, process, store, and provide as output the information needed to complete business tasks Computer application or app a computer software program that executes on a computing device to carry out a specific function or set of related functions Systems analysis those system development activities that enable a person to understand and specify what the new system should accomplish Systems design those system development activities that enable a person to describe in detail how the resulting information system will actually be implemented In a nutshell, systems analysis and design provides the tools and techniques you need as an information system developer to complete the development process: 1. Understand the need (business need). 2. Capture the vision. 3. Define a solution. 4. Communicate the vision and the solution. 5. Build the solution or direct others in building the solution. 6. Confirm that the solution meets the need. 7. Launch the solution application.

1. The System Development Life Cycle (SDLC) System development life cycle (SDLC) a framework that identifies all the activities required to research, build, deploy, and often maintain an information system. The six core processes required in the development of any information system: Identify the problem or need and obtain approval to proceed with the project. ■ Plan and monitor the project—what to do, how to do it, and who does it. ■ Discover and understand the details of the problem or the need—what is required? ■ Design the system components that solve the problem or satisfy the need — how will it actually work? ■ Build, test, and integrate system components—lots of programming and component integration. ■ Complete system tests and then deploy the solution—the need now is satisfied. ■

System development process or methodology a set of comprehensive guidelines for carrying out all of the activities of each core process of the SDLC Agile development an information system development process that emphasizes flexibility and rapid response to anticipate new and changing requirements during development Iterative development is an approach to system development in which the system is “grown” piece by piece through multiple mini projects called iterations. There are several benefits to iterative development.  For one, portions of the system can sometimes be deployed sooner.  Second, by taking a small portion and developing it first, the most difficult problems can be identified and addressed early in the project  Finally, developing a system in iterations makes the entire development process more flexible and able to address new requirements and issues that come up throughout the project Identify and document the specific business need and to define the project objectives. They might be called pre-project activities of Core Process 1: ■ Identify the problem and document the objective of the solution system. ■ Obtain approval to commence the project.

Day 1: The project actually begins with Day 1, which is essentially a planning day. The second SDLC core process—Plan and monitor the project—includes business analysis and project management activities. These Core Process 2 activities are completed on Day 1: ■ Determine the major components (functional areas) that are needed. ■ Define the iterations and assign each functional area to an iteration. ■ Determine team members and responsibilities.

Planning the Overall Project and the Project Iterations As is often the case, the list of system capabilities provides the foundation information for determining the overall project plan. The first step is to divide the system into several subsystems or components. Subsystem is an identifiable and fully functional part of a complete system

Planning the Rest of the First Iteration: The Supplier Subsystem The planning process for an iteration consists of these three steps: ■ Identify the tasks required for the iteration.  As these tasks are identified, they are compiled and organized. Sometimes, this organized list of tasks is called a work breakdown structure (WBS)  Part of this effort is trying to estimate how long each task will take. (in hours) ■ Organize and sequence these tasks into a schedule.  We can be very formal and use a sophisticated project scheduling tool, or we can just list the tasks in the order we think they need to be done.  The benefit of an iteration schedule is threefold. First, it helps the team organize its work so developers have enough time to think through the critical design issues before programming begins. Second, it provides a measuring rod to see if the iteration is on schedule. ■ Identify required resources (especially people), and assign people to tasks.

Day 2: Day 2 involves discovering and understanding details, which is a key part of systems analysis. These Core Process 3 activities include: ■ Do fact-finding tasks to understand the requirements.  Before the project commenced, a broad definition of requirements was developed.  There are various techniques to ensure that the fact finding is complete and thorough. These include interviewing the key users, observing existing work processes, reviewing existing documentation and existing systems, and even researching other companies and other systems.  The first step is to identify the key users who will define these details. ■ Develop a list of use cases and a use case diagram.  Identifying and describing use cases is the way to document what the users need to do with the system  “The purchasing agent ‘uses’ the system to ‘Look up a supplier.’” ■ Develop a list of classes and a class diagram  Domain classes identify those things in the real world that the system needs to know about and keep track of.  We look for all objects, or things, that the system uses or captures. Objects come in all types and variations, from tangible items (such as merchandise products that you can see and touch) to more abstract concepts that you cannot touch (such as a promotion).  Domain classes are the categories of objects identified, much like a table in a database represents the category of the records it contains.

Day 3: The purpose of Day 3 activities is to analyze in detail the use cases and domain classes that are scheduled to be implemented in the first iteration for the Supplier Subsystem. Included are these Core Process 3 activities: ■ Perform in-depth fact finding to understand details of each use case.  After working with the purchasing agents, developers determined the following use cases pertaining to the Supplier Information Subsystem: ■ Look up supplier ■ Enter/update supplier information ■ Look up contact information ■ Enter/update contact information ■

Understand and document the detailed workflow of each use case.

Use case diagram for the Supplier Information Subsystem



 

Activity diagram for the Look up supplier use case

One that you will learn later in this text is called a use case description. Another method is developing an activity diagram, which shows all the steps within the use case. Diagrams are quite easy for users to understand and critique. Activity diagram for the Look up supplier use case

■

Define the user experience with sketches of screens and reports needed for each use case.

Defining Screen Layout User-interface design includes creating how a system looks and how the user interacts with it.

Day 4: The primary focus of Day 4 is to design the various components of the solution system, corresponding to Core Process 4: Design System Components. Day 4 activities (Core Process 4) include the following: ■ Design the database structure (schema).  Designing the database uses the information provided by the domain class diagram to determine the tables, the columns in the tables, and other components.

■

Design the system’s high-level structure.  Best practice suggests that the designer complete most of the high-level structure design before writing code  One of the first questions encountered in software design is how and where to start. So far, we have compiled three sets of information that can answer that question: ■ Use cases, with activity diagrams ■ Domain classes, with accompanying diagrams ■ Pages and reports, with program and display logic specifications

Before we jump more into software design, let us briefly discuss the objective of systems design and what we expect the output or result to be. Object-oriented programs are structured as a set of interacting objects based on classes. To program, we need to know what the classes are, what the logic is within each class (i.e., the functions), and which classes must interact. This is the final objective of

systems design. We perform this design by starting at the very highest level and then drilling down to the lowest level until we have defined all the functions within each class.

Designing the Software Components Figure 1-18 shows the overall structure of the new system in terms of software components. First, note that the decision was made to build this application as a browser-based system designed for use on smartphones and tablets

Defining the Preliminary Design Class Diagram The Tradeshow System will be built by using object-oriented programming (OOP) techniques, beginning with developing the set of software classes and their methods that will be needed for the system. Figure 1-19 is a preliminary design class diagram for the Supplier Information Subsystem that identifies the software classes needed for the system. In Figure 1-19, we show only the problem domain design classes and the user-interface View layer classes. Problem domain design classes are usually derived from those classes that were identified during analysis activities—hence, the name: problem (user need) domain design classes. The design classes in Figure 1-19 include the attributes that are needed for the class. They also include method names of the important methods within each class. One final element in the design class diagram is the arrows that show where a class accesses the methods of another class.

Designing Subsystem Software Architecture

Once we have an overall structure and approach for implementing the new system, we begin to drill down to the software design for the subsystem. Notice that this subsystem is further divided into layers: a View layer and a Domain layer. One of the advantages of partitioning the system into layers is it is much easier to build and maintain. For example, the system will be browser based, but different browsers require different techniques. It is better not to get these complexities mixed in with the basic program functions. Hence, they are separated out into a distinct layer.

The View layer includes two classes that represent what is seen on the user interface—SupplierView and ContactView—as well as some JavaScript functions. The Domain layer includes two classes that interact with each other and with the database—Supplier and Contact.

Managing the Project Design is a complex activity with multiple perspectives—from high-level structural design to low-level detailed program design. The basic high-level software architectural structure is defined first, but midlevel and low-level design are often done concurrently with programming.

Day 5: A much better approach is to understand, design, and build small chunks of the system at a time. Day 5 activities include the following (Core 5 Process): ■ Create detail design. ■ Program the subsystem components.

Day 6: The focus of Day 6 activities is final testing, a step that is required before the system is ready to be deployed. Although there are many types of testing, we mention only two types at this time: overall system functional testing and user acceptance testing. Functional testing is usually a test of all user functions and is often done by a quality assurance team. User acceptance tests are similar in nature, but these are completed by the users, who test both the correctness of the system and its “fitness” to accomplish the business requirements.

Summary 1. Problem identification and approval: a. Identify the problem and document the objective of the solution system. b. Get approval for the project to be commenced. 2. Project planning and monitoring a. Determine the major functional areas which are needed for the system. i. Identify the subsystems of the whole system. b. Define the iterations and each functional area which will form part of the iteration. i. Define the work required in each iteration. ii. Schedule this work in a logical order of requirement leading to completion of the function. c. Define team members and responsibilities. i. Assign resources to the scheduled tasks. 3. Discover and understand the details (system analysis) a. Fact finding activities which identify the requirements. i. Understand the key stakeholders which are to be approached in providing the correct information. Review documentation, review the industry standards, review existing work processes. b. Develop use cases and use case diagrams. i. Use cases assist in defining what the user of system requires the system to do. Eg. Procurement must lookup supplier. c. Develop a list of classes and class diagrams. i. The classes represent real life objects which the system needs to know about in order to provide the desired output. The classes consist of attributes and methods which access and manipulate the attributes to provide the desired outputs. 4. Design system components a. Designing the databases is derived from the detailed information gathered from the classes. b. Design the systems high level structure before writing code. i. ii. iii.

Use cases, with activity diagrams Domain classes, with accompanying diagrams Pages and reports, with program and display logic specifications

5. Build, test and integrate the system a. Starting at a high level system architecture of a system component and drilling down into the classes for the system component the final system component is developed. b. First the high level software components are identified c. Design class diagrams are created which identify the problem domain (user need) and the user interface view layer classes. This also specifies which classes accesses the methods of other classes. d. The subsystem is divided into a view layer (user) and a domain layer (classes and databases) e. Program the subsystem components from a detailed design in small chunks. 6. Complete system tests and deploy the solution a. Complete final functional testing and user acceptance testing...