Software Development: An Introduction

Week 1: Introduction to Software Development

• Software development involves designing, creating, testing, and maintaining various software applications to be efficient, reliable, and easy to use.
• A software developer researches, designs, builds, tests, and implements software.
• Application Development refers to computer programming and maintaining source code.

Types of Developers

• Application Developer
• System Developer
• Web Developer
• Game Developer

Software Development Career Paths

• Back-end Developer
• Front End Developer
• Full Stack Developer
• Freelance
• Director
• Software Development Management
• CEO

Software Testing

• Software Testing evaluates a system or its components to determine if it meets specified requirements, identifies gaps, errors, or missing requirements.
• Software Testing analyzes software items to detect differences between existing and required conditions (defects/errors/bugs) and evaluates features.

Good Software Tester Qualities

• Passion
• Verbal and Written Communication
• Technical Skills
• Analytical Skills
• Attitude
• Productivity

Software Testing Career Paths

• Developer
• Manager
• Business Analyst
• Program Manager
• Scrum Master
• Test Engineer
• Automation Test Engineer
• Director
• CEO

Week 2: Software Development Life Cycle (SDLC)

• SDLC is a methodology for designing, developing, and testing software, aiming for high-quality software that meets or exceeds expectations.
• SDLC methodologies include pre-defined deliverables and artifacts created and completed by a project team to develop or maintain application.

Software Development Team Roles

• Project Sponsor: Provides high-level information and ensures alignment with company objectives.
• Project Manager: Leads the project and works closely with individuals.
• Customer: Receives the project's deliverable.
• Project Team Members (SMEs): Subject Matter Experts who ensure deliverables.

Additional Roles

• Software Engineers
• Designers
• Systems/Business Analyst
• Quality Assurance
• Trainers

Stage 1: Planning and Requirements Analysis

• Requirement analysis is the most critical stage in SDLC
• Senior members work with stakeholders and domain experts to plan quality assurance and identify risks.
• Represent and document software requirements, then obtain acceptance from project stakeholders via Software Requirements Specification (SRS).

Stage 2: Designing the Software

• Involves gathering knowledge of requirements, analysis, and design for the software project and creating a prototype.

Stage 3: Developing the Project

• Involves actual development, adhering to coding guidelines and programming tools set by management.

Stage 4: Testing

• Testing is conducted against requirements to solve needs.
• Unit testing, integration testing, system testing, and acceptance testing are performed.

Stage 5: Deployment

• Software is deployed once certified with no stated bugs or errors.

Stage 6: Maintenance

• Focuses on caring for the developed the product.

Week 3: Software Methodologies

• Software Methodology provides a structured framework to create, organize, deploy, and test software, completing tasks according to project requirements in a timely manner.

Waterfall Methodology

• Waterfall methodology includes requirements, analysis, design, implementation, testing, and maintenance.
• Advantages: Simplest to explain, structured approach, well-defined stages.
• Disadvantages: Very strict, stringent, inflexible, and not cost-effective.

Agile Methodology

• Agile methodology is built iteratively in small increments.
• Agile SDLC follows incremental development, changes are discussed with developers, project owners, and customers.
• It relies on anticipating and proactively scanning for changing requirements, development is iterative, not linear.

Agile Principles

• Highest priority is customer satisfaction through early and continuous delivery.
• Welcome changing requirements.
• Business people and developers work together daily.
• Build projects around motivated individuals.
• Face-to-face conversation is efficient and effective.
• Agile processes promote sustainable development.
• Continuous attention to technical excellence enhances agility.
• Simplicity is essential.
• Best architectures emerge from self-organized teams.
• Reflect and adjust behavior for efficiency.

Agile Advantages

• Quick delivery
• Emphasis on collaboration
• Direct communication and instant correction

Agile Disadvantages

• Best for small businesses
• Later documentation
• High customer dependency

Scrum Process

• Scrum builds complex products using an abstract, non-prescriptive framework.
• Scrum gained popularity in 1995, presented by Ken Schwarber and Jeff Sutherland.

Scrum Team

• Product owner is accountable for the product backlog.
• Development team member owns the sprint backlog. There are no managers or team leads.
• Scrum master adopted at enterprise level, considered a servant leader, not a top-down manager.

Scrum Events

• Sprint
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

Scrum Artifacts

• Product Backlog: A to-do list for the development team, it can contain requirements, enhancement requests, defects, user stories.
• Sprint Backlog: A subset of the product backlog containing items selected for the sprint, the team updates it throughout the sprint.
• Product Increment: Current "done" version, usable, value providing, and polished.

Scrum Definition

• Scrum involves regular meet-ups with team members and relies on incremental project development.
• All Scrum artifacts are either done or not done; the definition of done is understood by the Scrum team and external stakeholders.

Week 4: Functional & Non-Functional Requirements

• Software Engineering is an engineering discipline concerned with all aspects of software production, from system specification to maintenance.

Development Environments

• Development Environment where development takes place and code updates are made.
• Testing Environment allows quality assurance engineers to test new and changed code via automated or non automated techniques, faulty code can be removed.
• Staging Environment nearly exact replica of production, used to test application behavior before deployment but restricted to select users and is kept invisible from end-users ,and is not a substitute.
• Production Environment where software runs on a production server, releases can be deployed in phases to a segment of users.

Requirements Engineering

• Requirements Engineering establishes services that the customer needs from a system, defines what needs to be implemented, often classified as functional or nonfunctional.

Functional Requirements

• Functional Requirements outline how the system should behave and perform in specific situations and depend on software, users, and the organization, Describe functionality or system services.
• User Requirements are high-level statements written for customers describing services and constraints in natural language, should describe functional and non-functional requirements.

System Requirements

• Should describe system services in detail, define what should be implemented and can be illustrated using system models, and is Intended to be a basis for designing the system.

Functional Requirements Specification

• Requirement specifications establish what is wanted and exactly what is needed, and is a precursor.

How to Determine Requirements

• Determine requirements through interviewing, videotaping, reviewing documents and objects, and observation.

Techniques

• Business requirements
• Use cases
• User stories

The Five Ws and an H

• Requirements gathering with simplicity to assume users are non-technical.
• Who are the users?
• What does the app do?
• When will the app be used?
• Where are the users, and where is the infrastructure?
• Why does the business need the app?
• How should the app function?

Verifying vs Validating

• Verify: Are we building the software right?
• Validate: Are we building the right software?

Attributes of a Good Functional Requirement

• Unambiguous
• Testable
• Clear
• Understandable
• Visible
• Feasible
• Independent
• Atomic
• Necessary
• Implementation Free

Non-Functional Requirements

• Specify standards to judge a system's operation and define how a system is supposed to be as opposed to what it is supposed to do.

Key aspects

• Flexibility
• Portability
• Integrity
• Reliability
• Robustness
• Scalability and reusability

12 Non Functional Requirements

• Performance.
• Capacity and Scalability.
• Availability.
• Maintainability.
• Coding Standards
• Recovery

Guildelines for Writing Requirements

• Invent a standard format.
• Use language in a consistent way.
• Use "shall" for mandatory requirements.
• Highlight key parts.
• Avoid computer jargon, which relates to words and terms used in computing. To determine identify technical faults.

Week 4: User Story

• User stories are the standard for requirements analysis for agile teams, expressed simply and concisely, typically written on index cards or sticky notes.
• User stories consist of a Card, a Conversation, and Confirmation.

User Story Template

• Who are we building it for? (As a )
• What are we building? (I want <some goal/objective>)
• Why are we building it? (So that <benefit/value>)

INVEST Acronym

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

Epics

• Big user stories that can't be achieved within one iteration or sprint, it is on a matter of judgement.