Systems Development Life Cycle (SDLC)

Objectives

• Become familiar with the roles and skills of a systems analyst.
• Understand the fundamental systems development life cycle and its four phases.
• Understand the evolution of systems development methodologies.
• Become familiar with the fundamental principles of object-oriented systems analysis and design.
• Become familiar with the Unified Process, its extensions, and the Unified Modelling Language.

Introduction

• The systems development life cycle SDLC is the process of understanding how an information system can support business needs.
• This is achieved by designing a system, building it, and delivering it to users.
• The key person in the SDLC is the systems analyst.
• The systems analyst analyses the business situation, identifies opportunities for improvements and designs an information system to implement improvements.
• The primary objective of a systems analyst is to create value for an organization.
• For most companies, this means increasing profits.
• Government and not-for-profit organizations measure value differently.

The Systems Development Life Cycle

• Building an information system is similar to building a house.
• There are four fundamental phases: planning, analysis, design, and implementation.
• The SDLC is a process of gradual refinement.

Planning

• Planning understands why an information system should be built and how the project team will build it.
• Planning has two steps.

Planning - Project Initiation

• The system's business value to the organization is identified, in the form of a system request.
• A feasibility analysis will be conducted.
• The analyzed project is resented to an information systems approval committee, sometimes called a steering committee.
• The committee will decide whether the project should be undertaken.

Planning - Project Management

• The deliverable for project management is a project plan.
• The plan describes how the project team will develop the system.

Analysis

• The analysis phase focuses on who will use the system, what the system will do, and where and when it will be used.
• The analysis phase has three steps.

Analysis - Analysis Strategy

• An analysis strategy usually includes an analysis of the current system, called the 'as-is' system.
• The analysis will include the current system's problems and ways to design a new system, called the 'to-be' system.

Analysis - Requirements Gathering

• Gather requirements through interviews or questionnaires.
• Input from the project sponsor and other people leads to the development of a concept for a new system.
• The system concept is then used as a basis to develop a set of business analysis models.

Analysis - System Proposal

• Analyses, system concept, and models are combined into the system proposal.
• The proposal is presented to the project sponsor and other key decision makers.
• The key decision makers decide whether the project proceeds.

Design

• Design determines exactly how the system will operate.
• There are four steps in the design phase.

Design - Design Strategy

• Develops the system strategy by asking if the system will be developed by the company's own programmers, outsourced, or whether there will be an existing software package purchased.

Design - Architecture Design

• The architecture design determines the hardware, software, and network infrastructure.
• The architecture design also defines the interface design.

Design - Database and File Specifications

• Database and file specifications denote what data will be stored and where be stored.

Design - Program Design

• Program design specifies the programs that need to be written and exactly what each program will do.
• A feasibility analysis and project plan are re-examined and revised during design.
• Another decision is made by the project sponsor and approval committee about project termination or continuation.

Implementation

• In the final implementation phase, the system is built or purchased.
• There are three steps in the implementation phase.

Implementation - Construction

• During construction, the system is built and tested.
• Testing is one of the most critical steps in implementation.

Implementation - Installation

• During installation, the old system is turned off and the new system is turned on.
• A training plan will teach users how to use the new system and manage the changes caused by the new system.

Implementation - Support Plan

• There will be a formal or informal post-implementation review and identifying major and minor changes needed for the system.

Systems Development Methodologies

• A methodology is a formalized approach to implementing the SDLC, is a list of steps and deliverables.
• There are many different systems development methodologies.
• Each methodology is unique, based on the order and focus it places on each SDLC phase.
• A process-centered methodology emphasizes process models as the core of the system concept.
• Data-centered methodologies emphasize data models as the core of the system concept.
• Object-oriented methodologies attempt to balance the focus between process and data by incorporating both into one model.
• Another important factor in categorizing methodologies is the sequencing of the SDLC phases and the amount of time and effort devoted to each.
• Three different classes of system development methodologies will be discussed: structured design, rapid application development and agile development.

Structured Design

• Structured design falls under waterfall development.

Structured Design - Waterfall Development

• The key advantage of the structured design waterfall approach is it identifies system requirements long before programming and minimizes changes to the requirements as the project proceeds.
• The key disadvantages are that the design must be completely specified before programming begins and that a long time elapses between system proposal completion in the analysis phase and system delivery.
• This can take many months or years.

Structured Design - Parallel Development

• The primary advantage of this parallel development methodology is it can reduce system delivery time.
• There is less chance of changes in the business environment causing rework.
• Sometimes the subprojects are not completely independent which can be a disadvantage.
• In parallel development, design decisions made in one subproject can affect another.
• The end of the project can require significant integration efforts.

Rapid Application Development (RAD)

• RAD-based methodologies attempt to address both weaknesses of structured design methodologies by adjusting the SDLC phases.
• The aim is to get some part of the system developed quickly and into the hands of the users.
• Recommendation to use special techniques and computer tools to speed up analysis, design, and implementation phases.
• Suggested techniques and tools are computer-aided software engineering (CASE) tools, joint application design (JAD) sessions, fourth-generation or visual programming languages that simplify and speed up programming, and code generators that automatically produce programs from design specifications.
• A possible problem with RAD-based methodologies is managing user expectations.
• Due to the use of tools and techniques that improve speed and quality of systems development, user expectations of what is possible can change dramatically.
• As users better understand IT, the systems requirements can expand.

Rapid Application Development (RAD) - Phased Development

• Phased development breaks an overall system into a series of versions that are developed sequentially.
• Phased development-based methodologies offer the advantage of quickly getting a useful system in the hands of users.
• Users begin working with the system sooner, and are more likely to identify requirements sooner than with structured design.
• The major drawback to phased development is that users begin to work with systems that are intentionally incomplete.

Rapid Application Development (RAD) - Prototyping

• Prototyping performs the analysis, design, and implementation phases concurrently.
• All three phases are performed repeatedly in a cycle until the system is completed.
• A key advantage of prototyping is that it quickly provides a system with which the users can interact, even if it is not ready for widespread organizational use.
• Prototyping assures the users that the project team is working on the system and helps to refine real requirements quickly.
• The major problem with prototyping is that its fast-paced system releases make methodical analysis challenging.

Rapid Application Development (RAD) - Throwaway Prototyping

• Throwaway prototyping-based methodologies are similar to prototyping-based methodologies in that they include the development of prototypes.
• The prototypes are done at a different point in the SDLC and are used for a very different purpose than other methodologies.
• This balances the benefits of well-thought-out analysis and design phases with using prototypes to refine issues before a system is built.
• Delivery of the final system may take longer as compared to prototyping, but this usually produces more stable and reliable systems.

Agile Development

• All agile development methodologies are based on the agile manifesto and a set of twelve principles.
• Software is delivered early and continuously through the development process, satisfying the customer.
• Changing requirements are embraced regardless of when in the development process.
• Working software is delivered frequently to the customer.
• Customers and developers work together to solve the business problem.
• Motivated individuals create solutions and are provided with the tools and environment they need, and are trusted to deliver.
• Face-to-face communication within the development team is most efficient and effective for gathering requirements.
• The primary progress measure is working, executing software.
• Both customers and developers should work at a sustainable pace where the work level could be maintained indefinitely without any worker burnout.
• Simplicity and avoiding unnecessary work are essential.
• Self-organizing teams develop the best architectures, requirements, and designs.
• Development teams regularly reflect on how to improve their development processes.
• Agile approaches should be considered in some circumstances.
• Two popular examples of agile development methodologies are extreme programming (XP) and Scrum.
• Business environment
• Auditability
• The methodology recommends against large mission-critical systems that aren't carefully managed.

Agile Development - Extreme Programming

• XP is founded on four core values: communication, simplicity, feedback, and courage.
• XP requires rapid feedback to end users continuously, following the KISS principle, incremental changes to make the system grow, embracing change, and a quality-first mentality.
• Team members require development of additional skills, with continuous testing, simple coding done by pairs of developers, and close interactions with end users to build systems very quickly.
• Testing and efficient coding are core to XP.
• Code is tested each day and placed into an integrative testing environment where bugs will have their code backed out until completely free of errors.
• XP should work fine for small projects with highly motivated, cohesive, stable, and experienced teams.
• Success is doubtful if the project is not small or the teams aren't gelled.
• XP requires discipline, otherwise projects become unfocused and chaotic.
• XP is recommended only for small developer groups of under 10 members and not large applications.
• User input is very important, with the commitment of many business units.

DevOps

• Another category of systems development methodologies is DevOps.
• It incorporates ideas from both object-oriented approaches to systems development and lean manufacturing into the agile approaches.
• Two of the popular approaches are DAD and SAFe.
• Operations personnel will be included as development team members.
• Non-functional requirements, like security, can be addressed during the design of the system.
• Deployment is completed when a new chunk of software has passed a set of relevant tests.
• The new version is deployed in pieces over time; this is a rolling upgrade.

Custom Methodologies

• Custom methodologies support applying agile and object-oriented ideas to system development methodology itself.
• The goal is to support development with customization to the specific systems development project.
• A high-level framework will be used to create the project-specific method.
• Two of the approaches that have made progress in this area are Brian Henderson-Sellers' and of Ivar Jacobson's contributions.
• Both allow the team to pick and choose components of a methodology from a component repository to create a custom methodology.
• Care must be taken to ensure that each component is plug compatible by having compatible inputs and outputs.

Systems Analyst Roles and Skills

• Project members are change agents to improve an organization, build an information system to support them, and train and motivate others to use the system.
• This requires a wide range of technical, business, analytical, interpersonal, management, and ethical skills.
• Small organizations expect one person to perform many roles, while most large organizations build project teams with defined responsibilities.
• Positions include business analysts, system analysts, infrastructure analysts, change management analysts, and project managers.

Object-Oriented Systems Analysis & Design (OOSAD)

• Object-oriented approaches to developing information systems can use any of the traditional methodologies.
• Object-oriented approaches are most associated with a phased development RAD or agile methodology.
• Attempts to balance the emphasis between process and data.
• Any modern object-oriented approach to developing information systems must be use-case driven, architecture-centric, and iterative and incremental.

Object-Oriented Systems Analysis & Design (OOSAD) - Use-Case Driven

• Use-case driven approaches means that use cases are defining behaviour of the system.
• Describes how the user interacts with the system to perform activity.
• Identifies and to communicate requirements.
• Its simple.

Object-Oriented Systems Analysis & Design (OOSAD) - Architecture-Centric

• Architecture-centric approaches means that the underlying software specification drives the specification, construction, and documentation of the system.
• Analysis and design approaches should support at least three separate but interrelated architectural views of a system: functional, static, and dynamic.
• The functional, or external, view describes the behaviour of the system from the user's perspective.
• The structural, or static, view describes the system in terms of attributes, methods, classes, and relationships.
• The behavioural, or dynamic, view describes the behaviour of the system in terms of messages passed among objects and state changes within an object.

Object-Oriented Systems Analysis & Design (OOSAD) - Iterative and Incremental

• There is continuous testing and refinement throughout the life of the project.
• The systems analysts develop their understanding of a user's problem by building up three architectural views little by little.
• The systems analyst does this by working with the user to create a functional representation of the system under study.
• Then, the analyst attempts to build a structural representation of the evolving system and distributes the system’s functionality to create a behavioural representation.

Object-Oriented Systems Analysis & Design (OOSAD) - Benefits of Object-Oriented Systems Analysis and Design

• Can break complex systems into smaller, more manageable modules, working on the modules individually, and piecing them back together to form an information system.
• Easier to grasp, easier to share among team members, and easier to communicate to users.
• Creates reusable pieces.
• Saves time.

Object-Oriented Systems Analysis & Design (OOSAD) - Factors Leading to Object-Orientation

• Increasing abstraction
• Event-driven programming
• Spread of GUIs
• Modular software
• Lifecycle problems
• Model transitions
• Reusable software

The Unified Process

• The Unified Process is a specific methodology that maps out when and how to use the various Unified Modelling Language UML techniques for object-oriented analysis and design.
• The Unified Process is a two-dimensional systems development process described by phases and workflows.
• Phases are inception, elaboration, construction, and transition.
• Workflows include business modelling, requirements, analysis, design, implementation, test, deployment, configuration and change management, project management, and environment.

The Unified Modelling Language (UML)

• Grady Booch, Ivar Jacobson, and James Rumbaugh created a standard set of diagramming techniques known as the Unified Modelling Language (UML).
• The goal of UML was to provide a common vocabulary of object-oriented terms and diagramming techniques rich enough to model any systems development project from analysis through implementation.
• UML Version 2.5 defines 15 diagramming techniques used to model a system with one category for structure and another for behaviour.