CSC 411: SYSTEM ANALYSIS & DESIGN LECTURER: MR. AJAYI, O. O.

CHAP 1: INTRO TO SYSTEM ANALYSIS AND DESIGN 1.2: Intro to SA&D 1.3: Who is an Analyst? 1.4: System Development Life Cycle

1.1 INTRO TO SYSTEM A system can be generally defined as collection of parts to form a whole.

1.1 INTRO cont’d In hardware terms, it can mean the coupling of related components to form a working system.

1.1 INTRO cont’d In programing slang, it can be described as the integration of different modules to form a larger, complex and functioning system.

1.1 INTRO cont’d A system in a broader sense however can be defined as objects that react to an event over an interval of time.

1.1 Cont’d – CATEGORIZATION of SYSTEM Categorization I: Physical and tangible systems: An ‘off body’, visible, touchable and working system; e.g. transportation system, filling station system etc.

1.1 Cont’d Categorization II: Physical but not tangible systems: An ‘off-body’, less visible, untouchable and working system; e.g. economic system, financial system, information system etc.

1.1 Cont’d Categorization III: Non-physical systems: A ‘body/mind residence’, invisible, untouchable and working system; e.g. concept, ideals etc.

There are two things here: 1.2 SA&D There are two things here: System analysis, & System design

1.2 SA&D cont’d Breaking it, we define: System analysis as set of procedures/steps taken in identifying the need of a system.

1.2 SA&D cont’d Continuing…….: It involves studying the operations, strengths, limitations, and constraints of that existing or proposed system.

1.2 SA&D cont’d Coming to System Design now…: It involves the specification, structuring, modeling, construction (building) and implementation of the proposed or modified system.

SYSTEM ANALYSIS involves Planning and Analyzing; 1.2 SA&D cont’d GRAB d logic…: SYSTEM ANALYSIS involves Planning and Analyzing; SYSTEM DESIGN entails Designing and Implementing.

1.2 SA&D cont’d & concluded Putting them together….: SA&D can be described as the development life cycle that involves planning, analyzing, designing and implementing a system project.

1.3 Who is an Analyst? ….of course, a human personality, but…: A system analyst is one that facilitates the design and implementation of an information system and computer applications.

1.3 Who is an Analyst?...cont’d (2) He is one that understudies/analyzes a system and convince the management or stakeholders of the need for an automated system (in case of manual system) or redesigning (in case of a non-functioning/outdated computerized system).

1.3 Who is an Analyst?...cont’d (3) He is one that studies the problems and needs of an organization to determine how people, data, process, communications, and information technology can be integrated to achieve a business goal.

1.3 Who is an Analyst?...cont’d (4) He is one that is knowledgeable in problem analysis and technology-independent requirement analysis.

1.3 Who is an Analyst?...cont’d (5) He is one that evaluates the relevancy of an information system to an organization in lie with the organization’s mission and vision statements.

1.3 Who is an Analyst?...cont’d (6)…….fill in the gap (7) …….fill in the gap

1.3 Who is an Analyst?...cont’d – SELF EXERCISE What are his/her responsibilities? Feedback: ajanalyzer@gmail.com

1.4 SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC) This implies different stages that a system goes through before evolving.

1.4 cont’d……. LIFE COMPARISON…… SDLC processes can be likened to Building an House Project.

1.4 cont’d…..What do u see in a typical house built project? The house built system starts with a basic idea. The idea is transformed into a rough sketch and presented to the client for possible refinement and/or acceptance. A blueprint (mini design) is done. This presents much more details about the house. The house is built from the blueprint, re-examined in the light of the blueprint, and then delivered with constant and possibly contracted follow-up activities (maintenance).

….similarities Like the house system, SDLC has a similar set of four fundamental phases: Planning (D BASIC IDEA), Analysis (ROUGH SKETCH), Design (BLUEPRINT), and Implementation (ACTUAL CONSTRUCTION/DEVELOPMENT (from d BLUEPRINT), TESTING, DEPLOYMENT/DELIVERY, and then MAINTENANCE – FOLLOW UP).

SDLC Approaches/Models Different Analysts/Authors adopt different approaches/models to executing SDLC. Some use the fundamental steps directly, while some slightly and logically modify it.

SDLC Approaches/Models cont’d… Generally, two of such models/approaches are commonly and globally acceptable. These are: Waterfall Model/Approach Evolutionary Model/Approach From these, other MODELs sprang up by way of one modifications/enhancements or the other.

WATERFALL APPROACH/MODEL This model implements the SDLC in cascade (splitting) form, dividing the implementation aspect into sub-parts, but still pointing to the four (4) process steps of building a system.

Waterfall Model (with Feedback Loop) OR System Life Cycle Requirement Analysis and Definition/Specification Implementation and Unit Testing Integration and System Testing Operation and Maintenance System and Software Design Waterfall Model (with Feedback Loop) OR System Life Cycle

What each stage points to in the SDLC….. Stage No Waterfall SDLC 1. REQUIREMENT ANALYSIS & DEFINITION/SPECIFICATION PLANNING (stage1) & ANALYSIS (stage2) 2. SYSTEM & SOFTWARE DESIGN DESIGN (stage3) 3. IMPLEMENTATION, INTEGRATION & OPERATION IMPLEMENTATION (stage4)

Summarizing Waterfall Activities….. Requirement Analysis and Definition/Specification System specification System and Software Design System development Implementation/Unit Testing and Integration/System Testing   System validation Operation and Maintenance System evolution ……still four (4) basic steps (what a compliance!)

So, ……..four (4) system dev. activities…. Software Specification: This activity involves stating the functionalities (operations) of the information system/software as well as its constraints or limitations. Here, the requirement analysis and definition comes in.

….cont’d – DEVELOPMENT ACTIVITIES Software Development: This activity involves developing (producing) an information system/ software according to the particular specification given. This is where system and software design comes in.

….cont’d – DEVELOPMENT ACTIVITIES Software Validation: This activity checks the information system/software developed to ensure it conforms to the specification earlier given and also error-free. This is where implementation/unit testing and integration/system testing comes in.

….cont’d – DEVELOPMENT ACTIVITIES Software Evolution: This activity ensures that the information system/software produced is modifiable. For a standard- produced information system/software, maintenance or system modification should be with ease as requirement traceability can easily be carried out. This is where maintenance comes in.

Summarily, the four(4) steps/activities to developing a system are…… The specification is given The system/software is developed. The system/software is validated. The system/software is made modifiable.

EVOLUTIONARY DEVELOPMENT In this model, the system is first developed, deployed to the customer, and gets validated after getting the customer’s comment(s)/complaints. Unlike the waterfall model, here, the specification, development, and validation activities are culminated, that is, these three (3) activities are carried out concurrently with rapid feedback. EVOLUTIONARY DEVELOPMENT

…. the model…called EVOLUTIONARY: … …..the model…called EVOLUTIONARY: …..as situation occurred…the system evolve…BUILD FAST-FAST Approach…DESTROY & REBUILD Approach…MODIFY & RELEASE AGAIN Approach Specification Validation Development Initial Version Intermediate Version Final Version

….differences Waterfall Evolutionary Development The process is very visible The process is not visible It is suitable for large software   For developing relatively small software For development of systems with a with a long lifetime/lifespan For development of systems with a short lifetime/lifespan Systems are well structured Systems are usually poorly structured Requirement analysis carried out Requirement analysis omitted