System Development Life Cycle

Download as pdf or txt
Download as pdf or txt
You are on page 1of 31

GLS681

System Development Life


Cycle (SDLC)

Lecturer
IKHWAN MOHAMED
0195720789
LEARNING OBJECTIVES

By the end of this lecture you will

• Being Introduced to the Systems Development Life Cycle


• Learned about the stages (or steps) involved in system analysis.
• What is ‘waterfall model’ and other possible alternatives
WHY DO WE NEED THE SDLC?

• The software crisis of the late ‘60s and early ‘70s - computer become complex
• Systems were delivered years late – lacking of software engineer, lacking of programming
• They were over budget
• Unreliable
• Difficult to maintain – computer evolve fast..8 bit..16 bit..32 bit..64 bit..outdated programming
• Did not do what was required – there is no 2 way communations between client and system developer.
WHAT DOES THE SDLC DO?

• Systems Development Life Cycle was an attempt to establish a structured approach to systems
development
• For management, each stage of the life cycle was a milestone with an associated date and set of
deliverables.
SYSTEMS DEVELOPMENT
What is a System ?

• A collection of related components that interact to perform a task in order to accomplish a goal
• Windows system..ios system

What is system Development ?

The process of creating systems, developing them, and maintaining or enhancing them,
example system development in general vs in GIS ..?
SYSTEMS DEVELOPMENT METHODOLOGY

• A standard process followed in an organization to conduct all the steps necessary to analyze, design,
implement, and maintain information systems
• Two categories :
• Systems Development Life Cycle - SDLC
• Alternative methodologies
WHAT ARE THE PHASES OF THE SDLC
PLANNING PHASE

• In the Planning phase, project leaders calculating labor and material costs, creating a timetable with
target goals, and creating the project’s teams- Microsoft project
• Planning can also include feedback from stakeholders
• Stakeholders are anyone who stands to benefit from the application
• Try to get feedback from potential customers, subject matter experts, and sales reps.
• Planning should clearly define the scope and purpose of the application.
• It also sets boundaries to help keep the project from expanding or shifting from its original purpose.
• Example..college system – who r the stakeholders ?
DEFINE REQUIREMENTS

• determine what the application is supposed to do and its requirements


• For example, a social media application would require the ability to connect with a friend
• An inventory program might require a search feature.
• A customer wants to have an application which involves money transactions. In this case, the
requirement has to be clear like what kind of transactions will be done, how it will be done, in which
currency it will be done, etc.
• Example…why do we need gis system/aps to replace existing system ? Pro vs con ? …common question
being asked in fyp project…
DESIGN AND PROTOTYPING

• Architecture – Specifies programming language, industry practices, overall design, and use of any
templates
• User Interface – Defines the ways customers interact with the software, and how the software responds
to input
• Platforms – Defines the platforms on which the software will run, such as Apple, Android, Windows
version, Linux, or even gaming consoles
• Programming – Not just the programming language, but including methods of solving problems and
performing tasks in the application
• Communications – Defines the methods that the application can communicate with other assets, such
as a central server or other instances of the application
• Security – Defines the measures taken to secure the application, and may include SSL traffic encryption,
password protection, and secure storage of user credentials
SOFTWARE DEVELOPMENT

• A small project might be written by a single developer, while a large project might be broken up and
worked by several teams
• The coding process includes many other tasks such as finding and fixing errors and glitches
• Documentation can be a quick guided tour of the application’s basic features that display on the first
launch
• It can be video tutorials for complex tasks
• Written documentation like user guides, troubleshooting guides, and FAQ’s help users solve problems or
technical questions
TESTING

• It’s critical to test an application before making it available to users


• Testing should ensure that each function works correctly
• Different parts of the application should also be tested to work seamlessly together—performance test,
to reduce any hangs or lags in processing
• The testing phase helps reduce the number of bugs and glitches that users encounter
• This leads to a higher user satisfaction and a better usage rate
DEPLOYMENT

• In the deployment phase, the application is made available to users


• Many companies prefer to automate the deployment phase
• This can be as simple as a payment portal and download link on the company website
• It could also be downloading an application on a smartphone.
OPERATIONS AND MAINTENANCE

• In this phase, users discover bugs that weren’t found during testing
• These errors need to be resolved, which can spawn new development cycles.
• In addition to bug fixes, models like Iterative development plan additional features in future releases
THE WATERFALL APPROACH TO THE SDLC

• Waterfall Model is the very first model that is used in SDLC


• In this model, the outcome of one phase is the input for the next phase
• Development of the next phase starts only when the previous phase is complete.
• The design phase logically follows the requirements phase, the implementation phase follows the
design phase, and so on.
WATERFALL MODEL
WATERFALL STRENGTHS

• Waterfall model is the simple model which can be easily understood and is the one in which all the
phases are done step by step
• Deliverables of each phase are well defined, and this leads to no complexity and makes the project
easily manageable.
• Provides structure to inexperienced staff
WATERFALL DEFICIENCIES

• Waterfall model is time-consuming & cannot be used in the short duration projects as in this model a
new phase cannot be started until the ongoing phase is completed.
• Waterfall model cannot be used for the projects which have uncertain requirement or wherein the
requirement keeps on changing as this model expects the requirement to be clear in the requirement
gathering and analysis phase
• Does not reflect problem-solving nature of software development – iterations of phase
• Little opportunity for customer to preview the system (until it may be too late)
PROTOTYPING

• The prototype model is a model in which the prototype is developed prior to the actual software
• Prototype models have limited functional capabilities and inefficient performance when compared to
the actual software
• Dummy functions are used to create prototypes
• This is a valuable mechanism for understanding the customers’ needs.

Note: The final system is built based on a good prototype.


• Software prototypes are built prior to the actual software to get valuable feedback from the customer.
• Feedbacks are implemented and the prototype is again reviewed by the customer for any change
• This process goes on until the model is accepted by the customer.
INCREMENTAL SDLC MODEL

• Incremental Model is a process of software development where requirements divided into multiple
standalone modules of the software development cycle.
• In this model, each module goes through the requirements, design, implementation and testing phases
• Every subsequent release of the module adds function to the previous release
• The process continues until the complete system achieved.

INCREMENTAL MODEL STRENGTHS

• Errors are easy to be recognized.


• Easier to test and debug
• More flexible.
• Simple to manage risk because it handled during its iteration.
• The Client gets important functionality early.
SPIRAL MODEL
Planning - The planning phase includes requirement gathering wherein all the required information is
gathered from the customer and is documented. Software requirement specification document is created
for the next phase.

Risk Analysis - In this phase, the best solution is selected for the risks involved and analysis is done by
building the prototype.
• for example the risk involved in accessing the data from a remote database can be that the data access
rate might be too slow. The risk can be resolved by building a prototype of the data access subsystem.
• Engineering - Once the risk analysis is done, coding and testing are done.
• Evaluation - Customer evaluates the developed system and plans for the next iteration.
WHEN TO USE SPIRAL MODEL

• When creation of a prototype is appropriate


• When costs and risk evaluation is important
• For medium to high-risk projects
• Long-term project commitment unwise because of potential changes to economic prioritie
• Users are unsure of their needs
• Requirements are complex
• Significant changes are expected (research and exploration)
• New product line
SPIRAL MODEL STRENGTHS

• Users see the system early because of rapid prototyping tools


• Critical high-risk functions are developed first
• The design does not have to be perfect
• Early and frequent feedback from users
• Cumulative costs assessed frequently
SPIRAL MODEL WEAKNESSES

• Time spent for evaluating risks too large for small or low-risk projects
• Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive
• The model is complex
• Risk assessment expertise is required
• Developers must be reassigned during nondevelopment phase activities

You might also like