SDLC - The Software Development Lifecycle

What is Software Engineering?

Application of scientific principles for design and creation of software
Systematic approach to software development
- Design
- Build
- Test

Software Crisis:

Began in mid-1960s
Resulted from software development that ran over budget and behind schedule with unmanageable and buggy code
By the time old software solutions were developed, the newer technologies got the traction, and code refactoring would become necessary
Solutions didn’t scale well to large projects

Engineering principles:
Resolved as standardized methods in software engineering and computer-aided software engineering (CASE) tools were developed

Software engineer vs. software developer:

Engineer	Developer
Also developers	Narrower in scope than SE
Broad, big picture knowledge base	Creative approaches
Systematic development process	Write code to implement specific functionality and solve specific problems
Focus on structure

SE responsibilities:

Design, build and maintain software systems
Write and test code
Consult with stakeholders, third party vendors’ security specialists, and other team members

Software Development Life Cycle (SDLC):
Scientific approach to software development
Guides the software development process
Identifies discrete steps needed to develop software

Introduction to SDLC

Systematic process to develop high-quality software
Aims to produce software that meets requirements
Defined phases with their own processes and deliverables
Cycle of planning, design, and development
Minimizes development risks and costs

History of the SDLC:
Conceived of in the mid-1960s
A deliberate approach needed to manage complex projects
Initially used the waterfall method
Adapted to use iterative methods

Advantages of the SDLC:
Improves efficiency and reduce risks
Team members know what they should be working on and when
Facilitates communication among stakeholders
Team members know when development can move to the next phase
Respond to changing requirements
Solve problems early in the process
Reduces overlapping responsibilities

Phases of the SDLC

Organizations may have different names for each stage
Some organizations have more or fewer stages

Phase 1: Planning

Requirements;

Gathered
Analyzed
Documented
Prioritized

Prototyping:

Small-scale replica to clarify requirements
Tests design ideas
Can be developed at various stages of the SDLC

Software Requirements Specification:
Requirements are documented in the SRS
All stakeholders must agree

Phase 2: Design

Phase 3: Development

Development starts when the design document is finalized and sent to the developers to write code for it.

Phase 4: Testing

Code is tested to ensure stability, security, and that it meets requirements from the SRS
Bugs reported, tracked, fixed, and retested

Some common tests:
Unit testing
Integration testing
System testing
Acceptance testing

Phase 5: Deployment

Phase 6: Maintenance

Building Quality Software

Common software engineering processes:

Requirements gathering
Design
Coding for quality
Testing
Release
Documenting

Requirement Gathering

The SRS encompasses the process of collecting and documenting the set of requirements that the software needs to adhere to
It may include a set of use cases that describe the business needs and user flows that the software must implement

Software requirements can be classified into four broad categories:
1. Functionality
2. External & user interface
3. System features
4. Non-functional

Design

Transforming requirements into code
Breaking down requirements into sets of related components
Communicating business rules and application logic

Coding for quality

It refers to characteristics of the code, including attributes:

Maintainability
Readability
Testability
Security

Quality code must fulfill the intended requirements of the software without defects
Clean and consistent
Easy to read and maintain
Well documented
Efficient

Coding for quality entails a following set of coding practices during development;
Following coding standards
Using linters to detect errors
Commenting in the code itself to make it easy to understand and modify

Testing

The process of verifying that the software matches established requirements and is free of bugs

Identify errors, gaps, or missing requirements
Ensures reliability, security, performance, and efficiency
Software testing can often be automated or done manually

The types of testing are;
Unit testing
Integration testing
System testing
User acceptance testing (UAT) or Beta testing

Releases

Alpha	Beta	General Availability
Select stakeholders	All stakeholders	Stable
May contain errors	User testing	All users
Preview of functioning version	Meets requirements
Design changes may occur

Documenting

System documentation:

README files, inline comments, architecture and design documents, verification information, and maintenance guides

User documentation:

User guides, instructional videos, manuals, online and inline help

Requirements

Steps to gathering requirements:

Identifying stakeholders
Establishing goals and objectives
Eliciting requirements from the stakeholders
Documenting the requirements
Analyzing and confirming the requirements
Prioritizing

1) Identifying stakeholders

Key personnel:

Decision-makers
End-users
System administrators
Engineering Marketing
Sales
Customer support

2) Establishing goals and objectives

Goals: broad, long-term achievable outcomes

Objectives: actionable, measurable actions that achieve the goal

3) Eliciting, documenting, confirming

Elicit:

Surveys
Questionnaires
Interviews

Document:
Align with goals and objectives
Easily understood

Confirm:
Consistency
Clarity
Completeness

4) Prioritizing

Must-have
Highly desired
Nice to have

Requirements documentation:

Software requirements specification (SRS)
User requirements specification (URS)
System requirements specification (SysRS)

1) Software requirements specification (SRS)

Captures functionalities the software should perform
Establishes benchmarks / service-levels for performance
Purpose and scope
- Purpose
  - Who has access to the SRS
  - How it should be used
- Scope - Software benefits
Constraints, assumptions, dependencies
- Constraints: how the software must operate under given conditions
- Assumptions: required OS or hardware
- Dependencies: on other software products
Requirements
- Functional: functions of the software
- External interface: users and interactions with other hardware or software
- System features: functions of the system
- Non-functional: performance, safety, security, quality

2) User requirements specification (URS)

Describe business need and end-user expectations
User stories:
- Who is the user?
- What is the function that need to be performed?
- Why does the user want this functionality?
Confirmed during user acceptance testing
Often combined into the SRS

3) System Requirements Specification (SysRS)

Outlines requirements of the system
Broader than an SRS
Contains;
- System capabilities
- Interface and user characteristics
- Policy
- Regulation
- Personnel
- Performance
- Security
- System acceptance criteria
- Hardware expectations

The Software Building Process and Associated Roles

Software Development Methodologies

Common development methodologies:

A process is needed to clarify communication and facilitates information sharing among team members.

Some of these methodologies are:

Waterfall

V-shape model

Agile

Sequential vs. iterative:

Waterfall pros and cons

V-shape model pros and cons

Agile pros and cons

Software Versions

Software versions are identified by version numbers, indicate:
- When the software was released
- When it was updated
- If any minor changes or fixes were made to the software
Software developers use versioning to keep track of new software, updates, and patches

Version numbers:
Version numbers can be short or long, with 2, ,3, or 4 set
Each number set is divided by a period
An application with a 1.0 version number indicates the first release
Software with many releases and updates will have a larger number
Some use dates for versioning, such as Ubuntu Linux version 18.04.2 released in 2018 April, with a change shown in the third number set

What do version numbers mean?

Some version numbers follow the semantic numbering system, and have 4 parts separated by a period
the first number indicates major changes to the software, such as a new release
The second number indicates that minor changes were made to a piece of software
The third number in the version number indicates patches or minor bug fixes
The fourth number indicates build numbers, build dates, and less significant changes

Version compatibility:

Older versions may not work as well in newer versions
Compatibility with old and new versions of software is a common problem
Troubleshoot compatibility issues by viewing the software version
Update software to a newer version that is compatible
Backwards-compatible software functions properly with older versions of files, programs, and systems

Software Testing

Integrate quality checks throughout SDLC
Purpose
- Ensure software meets requirements
- Error-free software

Test cases:

Three types of testing:

Functional testing:

The purpose of functional is to check:

Usability
Accessibility

Non-functional testing

Its attributes are:

Performance
Security
Scalability
Availability

Non-functional testing questions:

How does the application behave under stress?
What happens when many users log in at the same time?
Are instructions consistent with behavior?
How does the application behave under different OSs?
How does the application handle disaster recovery?
How secure is the application?

Regression Testing

Confirms changes don’t break the application
Occurs after fixes such as change in requirements or when defects are fixed

Choosing test cases for regression testing:

Testing levels

Unit → Integration → System → Acceptance

Unit testing

Test a module code
Occurs during the build phase of the SDLC
Eliminate errors before integration with other modules

Integration testing

Identify errors introduced when two or more modules are combined
Type of black-box test
Occurs after modules are combined into larger application

Purpose of integration testing:

System testing

Compliance with SRS
Validate the system
Functional and non-functional
Staging environment

Acceptance testing

Software Documentation

Written assets
Video assets
Graphical assets

Product vs. process documentation:

Product Documentation Process Documentation

Relates to product functionality Describes how to complete a task