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

2. 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

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

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

5. 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.

6. 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.

7. 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.

8. 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.

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

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

11. 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.

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

13. 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.

14. 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.

15. 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.

16. 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.

17. 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).

18. 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.

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

20. 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.

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

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

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

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

25. 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).

26. ….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).

27. 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.

28. 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.

29. 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.

30. 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

31. 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)

32. 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!)

33. 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.

34. ….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.

35. ….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.

36. ….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.

37. 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.

38. 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

39. …. 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

40. ….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