Systems Development Life Cycle (SDLC)

Systems Development Life Cycle (SDLC)

• SDLC is a term in systems, information, and software engineering.
• It is used to define the process of planning, creating, testing, and deploying an information system.
• SDLC consists of steps or phases and provides a model for lifecycle management.
• The goal of SDLC is to produce cost-efficient, effective, and high-quality products.
• The SDLC methodology stages are analysis, construction, testing, release, and maintenance.
• System lifecycle is an organizational process for developing and maintaining systems.
• It establishes a system project plan with processes and sub-processes.
• System development lifecycle combines activities referred to as a system development lifecycle.
• In system analysis and design, the system development lifecycle is the software development lifecycle,.
• System development is a set of activities, methods, deliverables, and tools to develop and maintain systems and software.

Phases of System Development Life Cycle

• Preliminary study is the first phase.
• Conducting a feasibility study is the second phase.
• Detailed system study.
• System analysis.
• System design.
• Coding.
• Testing.
• Implementation.
• Maintenance is the last phase.
• Systems initiation consists of the preliminary, feasibility and detailed system studies.
• Systems implementation consists of coding, testing, implementation and maintenance

Systems Development Process Overview

• System initiation involves planning a project to define the business scope, goals, schedule, and budget.
• Technical feasibility assesses the practicality and staff expertise.
• Operational feasibility assesses whether a solution fulfills user requirements and how it impacts their work.
• Economic feasibility assesses cost-effectiveness.
• Schedule feasibility assesses if a solution can be designed and implemented in time.
• System analysis involves studying a business problem to recommend improvements and specify requirements.
• System design involves the specification of a technical, computer-based solution based on system analysis.
• System implementation is the construction, installation, testing, and delivery of a system into production.

General Problem-Solving Approach

• Identify the problem clearly.
• Analyze and understand the problem thoroughly.
• Identify specific solution requirements and expectations.
• Explore alternative solutions and select the optimal one.
• Design the selected solution in detail.
• Implement the solution methodically.
• Evaluate the results, and if necessary, return to the initial steps.

Systems Analyst

• Systems analysts specialize in analyzing organizational needs to improve business processes and technology.
• Systems analysts identify problem areas needing action.
• Systems analysts identify opportunities for improvement.
• Systems analysts direct changes to a situation.
• Systems analysts require information technology knowledge.
• Systems analysts require computer programming experience and expertise.
• Systems analysts require general business knowledge
• Systems analysts require general problem-solving skills
• Systems analysts require good interpersonal communication skills
• Systems analysts require good interpersonal relations skills
• Systems analysts require flexibility and adaptability
• Systems analysts must have character and ethics

Requirements Discovery

• Systems analysis is a technique to decompose a system into components for studying their interactions.
• Requirements discovery identifies system problems and solution needs from the user community.
• System requirements are what the information system must do.
• System requirements are also business requirement.
• PIECES classifies system requirements

PIECES Classification of System Requirements

• Performance requirements indicate the system performance to meet user needs.
• Information requirements indicate pertinent user information in terms of content, timelines, ect.
• Economy requirements indicate how the system will reduce costs or increase profits.
• Control and security requirements define the operational environment and security levels.
• Efficiency requirements indicate the system's ability to produce outputs with minimal waste.
• Service requirements focus on the system's reliability, flexibility, and expandability.

Results of Incorrect Requirements

• The system may exceed the projected costs.
• The system may not be delivered on time.
• The system may fail to meet user expectations.
• Maintenance costs may become excessively high.
• The system may be prone to errors and downtime.
• The reputation of the IT staff will be tarnished.

Criteria to Define System Requirements

• Requirements should be consistent.
• Requirements should be complete.
• Requirements should be feasible.
• Requirements should be truly needed and fulfill the purpose of the system
• Requirements should be accurate.
• Requirements should be traceable.
• Requirements should be verifiable.

Model-Driven Analysis Methods

• Model-driven analysis uses pictorial system models to document and validate systems.
• The system model becomes a blueprint for designing and improving the system.
• A model represents reality or vision, often using pictures.
• Structured analysis is a model-driven technique used to analyze existing systems or define new ones.
• Models illustrate component pieces, processes, inputs, outputs, and files.
• Information engineering (IE) is a model-driven and data-centered technique for designing and managing information systems.
• IE models illustrate and synchronize data and processes.
• Object-Oriented Analysis (OOA) integrates data and process concerns into objects.

Accelerated Systems Analysis Approaches

• Approaches emphasize prototypes to identify business and user requirements quickly for new systems.
• Discovery prototyping identifies user business needs through quick implementations.
• A prototype is a small-scale sample of the desired system.
• Prototypes cater to the need to visualize wants.
• Prototypes can become preoccupied with aesthetics prematurely.
• Prototypes can encourage premature focus on design.
• Users may overestimate the completion speed of using prototyping tools.
• Rapid Architected Analysis derives system models from existing systems or discovery prototypes.
• Reverse engineering generates a system model from program code automatically.

Fact-Finding

• Fact-finding collects information about system problems, opportunities, solution requirements and other priorities.
• Techniques of fact-finding: sampling, observation, questionnaires, interviews, JRP, and Agile Methods.
• Sampling of documents selects representative examples of documents, forms, databases, etc.
• Observation involves watching the current system in action.

Sampling

• Sampling collects representative documents, forms, and records.
• Sampling sources: organization charts and more.
• Sampling sources: memos.
• Sampling sources: standard operating procedures.
• Sampling sources: completed forms.
• Sampling sources: screens and reports.
• Sampling sources: samples of databases.
• Sampling sources: flowcharts.
• Sampling completed rather than blank forms can determine data types and sizes.

Observation

• Observation is a technique where the systems analyst participates in or watches activities to learn about the system.
• Observation guidelines include determining observational factors.
• Observation guidelines include obtaining permission.
• Observation guidelines include informing subjects of the reason for the observation.
• Observation guidelines include keeping a low profile.
• Observation guidelines include taking notes.
• Observation guidelines include reviewing notes.
• Observation guidelines include avoiding interruption.
• Observation guidelines include avoid assumptions.

Questionnaires

• Questionnaires collect information and opinions from respondents.
• Questionnaires are special-purpose documents.
• Free-format enables open answers.
• Fixed-format provides predefined answers.
• Types of fixed-format questions: multiple-choice questions.
• Types of fixed-format questions: rating questions.
• Types of fixed-format questions: ranking questions.

Developing a Questionnaire

• Determine necessary facts and opinions and who to collect them from.
• Decide on free- or fixed-format questions.
• Write the questions precisely.
• Test questions before use.
• Duplicate and distribute the questionnaire.

Interviews

• Interviews collect information through face-to-face interaction with specific goals.
• Interviews can be used to find, verify, and clarify facts.
• Interviews can be used to generate enthusiasm
• Interviews can be used to get end-users involved
• Interviews can be used to identify requirements.
• Interviews can be used to solicit ideas and opinions

Types of Interviews

• Unstructured interviews have a general subject.
• Structured interviews have specific questions.
• Open-ended questions allow broad responses.
• Closed-ended questions have specific choices.
• Select interviews.
• Prepare for the interview. Observe these procedures during the interview:
• Follow up on the interview.
• Avoid loaded, leading, biased and threatening types of questions.
• Be courteous.
• Listen carefully.
• Maintain control.
• Probe to get full stories. -Observe verbal and non-verbal communications.
• Be patient.
• Keep the interviewee at ease.
• Maintain control

Interview Don'ts

• Continuing an interview unnecessarily.
• Assuming an answer is finished or leading nowhere.
• Revealing verbal and nonverbal clues.
• Using jargon
• Revealing personal biases.
• Talking instead of listening.
• Assuming anything about the topic and the interviewee.
• Tape recording.

Guidelines for Communicating and Body Language

• Approach sessions with a positive attitude.
• Set the other person at ease.
• Show them you’re listening.
• Ask questions and take notes.
• Don’t make assumptions.
• Body language communicates nonverbally.
• Examples include facial expression, eye contact and posture.
• Proxemics involves spatial relations.
• The intimate zone is up to 1.5 feet.
• The personal zone is from 1.5 to 4 feet.
• The social zone is from 4 to 12 feet
• Public zone is more than 12 feet.

Joint Requirements Planning (JRP)

• JRP is structured group meetings to analyze problems and define requirements.
• JRP is a subset of joint application development.
• JRP participants: sponsors, facilitators, users, scribes and IT staff.

Steps to Plan a JRP Session

• Select a location: away from the workplace, requires rooms, equipment.
• Select participants with time for release.
• Prepare the agenda with documented briefings.

Guidelines for Conducting a JRP Session

• Do not deviate from the agenda.
• Complete on schedule.
• Have a scribe takes notes.
• Eliminate technical jargon.
• Do not forget conflict resolution.
• Give ample breaks.
• Encourage consensus
• Encourage participation, don't allow individuals to dominate the session
• Attendees should abide by ground rules.
• Brainstorm to generate ideas.
• Isolate the appropriate people
• Make sure everyone understands the purpose.
• Appoint one person to record the ideas.
• Remind everyone of brainstorming rules.
• Within a specified time period, team members should call out their ideas.
• Analyze and evaluate the ideas after recording ideas.
• Refine, combine, and improve the ideas that were generated earlier.
• Joint requirements actively involve users and management.
• Joint requirements greatly reduces development time.
• Joint requirements incorporating prototyping confirms requirements.

Agile Method

• The integration of various approaches of systems analysis and design for applications
• Fact-finding strategy reminders include learning from documents.
• Strategy includes observing the system.
• Strategy includes questionnaires.
• Strategy includes interviews.
• Strategy includes building discovery prototypes,
• Strategy includes validations.
• Strategy includes following up to verify.