NAME: Malcom Kipkemoi Ronoh

STUDENT ID: BBIT/2022/51184

COURSE TITLE: Software Engineering

Introduction

Software Engineering is a framework for building software with an engineering approach to

development.
It emphasizes systematic, disciplined, and quantifiable methods for creating high-quality,
cost-effective software.
Software combines instructions, data structures, and documents. The discipline seeks
solutions to simple and
complex problems while maintaining cost-effectiveness.

The Evolving Role of Software

Software serves dual roles:

1. As a product that manages and displays information.
2. As a vehicle to deliver products such as operating systems and communication tools.

Key characteristics of software include:

- It is engineered, not manufactured.
- It deteriorates with changes but doesn't wear out.
- It is custom-built, not assembled from pre-existing components.
The Changing Nature of Software

Software categories include:

- System software (supports other programs).
- Embedded software (controls consumer and industrial products).
- AI software (uses algorithms to solve complex problems).
- Application, engineering, scientific, and web-based software.

Legacy Software

Legacy software refers to older programs with poor design, convoluted code, and lack of
documentation.
Evolution occurs due to needs for compatibility with modern environments and new
business requirements.

Software Myths

Myths perpetuate misinformation in software development, categorized as:

- Management Myths: Overconfidence in tools, procedures, and team size for project
timelines.
- Customer Myths: Beliefs that objectives can suffice without detailed specifications.
- Practitioner’s Myths: Misconceptions about job completion and quality assurance.

Software Engineering - A Layered Technology

A layered technology comprises:

- Quality Focus: The foundation of software engineering.
- Process: Activities and methods for development.
- Tools: Support for methodologies through automation.

Process Framework and CMMI

The process framework involves communication, planning, modeling, construction, and

deployment. Activities like
tracking, quality assurance, and configuration management are umbrella activities.
Capability Maturity Model Integration (CMMI)
provides levels for process maturity:
- Levels range from 0 (Incomplete) to 5 (Optimized), focusing on refinement and quality
control.
Process Models

Software process models guide development, including:

- Waterfall Model: Sequential approach but lacks flexibility.
- Incremental Model: Adds functionality over iterations.
- RAD Model: Fast cycles but requires modular design.
- Evolutionary Models: Iterative and adaptable (Prototyping, Spiral, Concurrent models).
- Unified Process: Incorporates object-oriented and UML methods for structured
development.

Agile Process Models

Agile methods focus on iterative development, rapid delivery, and client interaction. Phases
include requirements gathering, design, construction, testing, and feedback. Scrum and
Crystal methodologies highlight collaboration and flexibility.
Extreme Programming (XP) emphasizes simplicity and adaptability in small teams with
evolving requirements.

UNIT II: SOFTWARE REQUIREMENTS

Introduction to Software Requirements

The IEEE defines software requirements as conditions or capabilities required by a user to

solve a problem or achieve an objective.
They also serve as documented representations of these conditions. Software requirements
encompass both:
1. The user's view (external) describing system services and constraints.
2. The developer's view (internal) focusing on the system's operational characteristics.

Types of Requirements

1. **Functional Requirements**: Define services the system should provide, its behavior in
specific situations, and reactions to inputs.
2. **Non-Functional Requirements**: Specify constraints such as usability, efficiency, and
reliability.
3. **Domain Requirements**: Relate to the specific application and include constraints and
characteristics unique to the system.
Challenges in Natural Language Specification

Natural language requirements often lead to:

- Lack of clarity due to ambiguity.
- Confusion from over-flexibility.
- Difficulty in modularizing requirements effectively.

Structured Language Specification

To address these challenges, structured specifications ensure uniformity and

modularization by:
- Using templates to standardize system requirements.
- Including control constructs and graphical elements for better clarity.

Software Requirements Document (SRS)

The SRS is an official statement detailing what a system must achieve. It focuses on 'what'
the system does rather than 'how' it does it.
Essential elements include:
- Specification of external system behavior.
- Constraints on implementation.
- Changeability and maintainability.
- Reference tool for system maintainers.

Requirements Engineering Process

This process ensures a comprehensive documentation of requirements and involves:

1. Feasibility Study: Assessing the business value and technical feasibility of the system.
2. Requirements Elicitation: Discovering requirements through stakeholder interactions
and documentation reviews.
3. Specification: Converting requirements into a structured, standard form.
4. Validation: Ensuring the documented requirements align with customer expectations.

Techniques for Requirements Elicitation

1. Viewpoints: Recognizing multiple perspectives from stakeholders to identify potential

conflicts.
2. Interviews: Conducting closed or open-ended discussions with stakeholders to derive
system requirements.
3. *Scenarios: Using real-life examples to describe system interactions and outcomes.
4. Use Cases: Employing UML diagrams to outline specific interactions and actors.

System Models

System models provide abstractions of the system to enhance understanding and include:
1. Context Models: Highlight the relationships between subsystems.
2. Behavioral Models: Describe data flows and state transitions.
3. Data Models: Depict the logical structure of system data using entity-relationship
diagrams.
4. Object Models: Represent system components as objects with attributes and behaviors.
5. Inheritance Models: Show hierarchies where objects inherit attributes and behaviors.

Requirements Management

Managing requirements is critical as they often change due to evolving business needs. This
involves:
- Traceability: Linking requirements to stakeholders, dependent requirements, and design
modules.
- Change Management: Analyzing the impact, cost, and risks of changes.
- Planning: Defining unique identifiers for requirements and using tools for automation.

UNIT III: DESIGN ENGINEERING

Design Process and Design Quality

Design engineering encompasses principles, concepts, and practices leading to the

development of high-quality systems or products. Design involves creating
representations or models of software, focusing on software architecture, interfaces, and
components necessary for implementation. Quality is integral to design and should
exhibit firmness, utility, and consistency. A well-structured design serves as the
foundation for construction.

Quality Guidelines

 Architectural Styles/Patterns: Use recognizable architectural styles to structure

the system.
 Modularity: Design should be logically partitioned into elements or subsystems.
 Clear Representation: Distinct data, architecture, interface, and component
representations.
 Appropriate Data Structures: Proper structures for implementing classes.
  Independent Functional Characteristics: Components should operate
independently.
 Simple Interfaces: Reduce complexity in connections between components.
 Repeatable Methods: Use proven methods for creating repeatable designs.

Quality Attributes (FURPS)

 Functionality: Includes feature set, capabilities, and system security.

 Usability: User-friendliness, aesthetics, consistency, and documentation.
 Reliability: Frequency and severity of failures, measured by MTTF (Mean Time To
Failure).
 Supportability: Extensibility, adaptability, and serviceability of the design.

Design Concepts

 Abstraction: The process of simplifying complex systems into higher-level models.

 Architecture: The structure and organization of software components and their
interconnections.
 Patterns: Reusable templates for solving recurring design problems.
 Modularity: Breaking down the software into manageable, independent modules.
 Information Hiding: Concealing the internal workings of a module to reduce
complexity and increase maintainability.
 Functional Independence: Modules should focus on single tasks with minimal
interaction with other modules.
 Refinement: Elaboration of higher-level abstractions into detailed components.
 Re-factoring: Simplifying and improving the design without changing functionality.
 Design Classes: Different classes represent layers in design architecture, such as
user interface classes, business domain classes, and persistent classes.

Design Model

 Data Design: High-level representation of data that is progressively refined.

 Architectural Design: The structure of program components and how they
interact.
 Interface Design: Focuses on the detailed drawings and descriptions of system
interactions.
 Deployment Design: Specifies how the software will be allocated in the physical
computing environment.
 Component Design: Describes the internal details of each software component.

Architectural Design

 Software Architecture: The system's structure, including components, their

properties, and interconnections. It enables effective analysis of design effectiveness
and allows for easier adjustments at early stages of development.
 Data Design: Translates data objects into data structures and database
architectures.
Architectural Styles

 Data-flow Architecture: Visualizes data flow through filters and pipes.

 Call and Return Architecture: Uses main programs and subprograms for flexible,
scalable systems.
 Object-Oriented Architecture: Focuses on encapsulating data and operations into
objects.
 Layered Architecture: Organizes the system into layers, with each layer interacting
with others.

Object-Oriented Design Process

 Object Identification: Identifying objects by analyzing grammar, tangible entities,

behaviors, or scenarios.
 Design Models: Static and dynamic models help describe object relationships and
interactions.
 Object Interface Specification: Specifies the details of object interfaces.

Golden Rules for User Interface

1. Place the User in Control: Ensure flexibility and ease of interaction, including undo
and interrupt options.
2. Reduce the User’s Memory Load: Streamline tasks and interface design to
minimize the need for remembering information.
3. Make the Interface Consistent: Maintain consistency in design and interaction
models to avoid user confusion.

User Interface Analysis and Design Process

The process is iterative, involving:

1. User, Task, and Environment Analysis: Understanding the users and their
context.
2. Interface Design: Defining the interface objects and actions required for user tasks.
3. Interface Construction: Building a prototype and finalizing the interface.
4. Interface Validation: Ensuring the design meets user requirements.

User Interface Design Models

 User Model: Profiles the system’s users.

 Design Model: A full design incorporating data, architecture, and interface
representations.
 Implementation Model: Represents the “look and feel” of the interface, with syntax
and semantics details.
UNIT IV : TESTING STRATEGIES AND SOFTWARE METRICS
Introduction to Software Testing Strategies
Testing is an essential activity in software development, responsible for uncovering errors
that occur during design and construction. It is a crucial process, often accounting for 40%
of the total project effort. A structured testing strategy is necessary to ensure quality
assurance throughout the software lifecycle. This strategy includes test planning, case
design, execution, and the collection of relevant data.

Software testing involves both verification and validation processes. Verification ensures
the software functions correctly, i.e., building the product right. Validation, on the other
hand, ensures the software meets the customer’s needs, i.e., building the right product.

Strategic Approach to Software Testing

A software testing strategy should be planned in advance and follow a systematic approach.
It should have the following characteristics:

 Use of Formal Technical Reviews (FTR)

 Start at the component level, and progress to the entire system

 Employ different techniques at various points

 Collaboration between developers and testers

 Include debugging as part of the process

Testing strategies for conventional software can be represented as a spiral with four key
levels:

1. Unit Testing

2. Integration Testing

3. Validation Testing

4. System Testing

Types of Software Testing

1. Unit Testing: Focuses on individual software components, verifying that each unit
performs as expected. This is done using path testing to ensure full coverage.

2. Integration Testing: Addresses potential issues when modules are combined.

Techniques such as top-down, bottom-up, and the sandwich strategy are used for
integration.

3. Validation Testing: Validates that the software meets the specified requirements
and behaves as expected from the customer’s perspective.
 4. System Testing: Tests the complete system, including hardware, software, and
databases, to ensure proper interaction among all components.

Testing Techniques and Methods

 Black-Box Testing: Focuses on functional requirements and tests the system's

behavior without examining its internal structure. Techniques used include
equivalence partitioning, boundary value analysis, and orthogonal array testing.

 White-Box Testing: Also known as glass-box testing, examines the internal

workings of the system. Techniques like basis path testing, condition testing, and
loop testing are employed to ensure all paths and logical decisions are tested.

Validation Testing
This testing ensures that the software meets the functional, behavioral, and performance
requirements outlined by the customer. Validation includes activities such as alpha and beta
testing.

 Alpha Testing: Conducted by the developers in a controlled environment.

 Beta Testing: Performed at the customer’s site, where they test the software in a
real-world environment.

System Testing Types

System testing involves testing the software within the broader system context, focusing on
overall functionality:

 Recovery Testing: Ensures the system recovers from faults within an acceptable
time.

 Security Testing: Verifies the system’s protection mechanisms against

unauthorized access.

 Stress Testing: Evaluates system performance under extreme conditions.

 Performance Testing: Assesses the software’s performance, including speed,

memory usage, and response time.

Debugging
Debugging is an essential post-testing activity aimed at identifying and fixing software
errors. The debugging process can be approached using several strategies:

 Brute Force Method: Involves tracing the code by adding output statements and
using memory dumps.

 Backtracking: Traces the code backward from the point where the error was
detected.
  Cause Elimination: A systematic approach based on binary partitioning, testing
hypotheses to isolate the error's root cause.

Software Quality Metrics

Software quality refers to conformance to functional and performance requirements.
Metrics are used to assess software quality by evaluating attributes like correctness,
reliability, and efficiency. Key software quality models include McCall’s quality factors and
ISO 9126 quality factors.

Product Metrics for Software Development

Product metrics are essential for measuring various aspects of software quality during the
development lifecycle. These metrics can be applied to analysis models, design models,
code, testing, and maintenance.

 Function Points: Measure the functionality delivered by a system, including

external inputs, outputs, and inquiries.

 Design Structure Quality Index (DSQI): Measures design structure quality,

focusing on module independence, data dependency, and database structure.

 Halstead Metrics: Provide a quantitative measure of software complexity and code

quality.

Metrics for Process and Product

Software measurement involves both direct and indirect metrics. Direct measures include
cost, effort, and product size (e.g., lines of code), while indirect measures focus on the
product's functionality, efficiency, and reliability.

 Direct Measurement: Involves quantifiable aspects such as lines of code, execution

speed, and defect rates.

 Indirect Measurement: Includes measures like functionality, maintainability, and

complexity.

Maintenance Metrics
Software maintenance is a crucial phase that ensures the software continues to meet user
needs and adapts to changes. Maintenance metrics include the number of modified modules
and the Software Maturity Index (SMI), which evaluates the stability and maturity of the
software.
UNIT V: RISK MANAGEMENT

Risk management focuses on identifying, analyzing, and mitigating risks to reduce their
impact on a project. It aims to ensure project continuity and minimize losses.

Reactive vs Proactive Risk Management

Reactive: Monitors potential risks and reserves resources for mitigation.
Proactive: Identifies risks, assesses their probability and impact in advance.

Software Risks
Characteristics: Uncertainty and Loss. Types of risks include:
1. Project Risk: Affects schedule and costs.
2. Technical Risk: Impacts quality and timeliness.
3. Business Risk: Threatens software viability.
4. Known Risks: Identified through evaluation.
5. Predictable Risks: Based on past experience.
6. Unpredictable Risks: Difficult to foresee.

Risk Identification
Steps in Risk Identification:
1. Identify possible risks.
2. Create a checklist.
3. Categorize into components like performance, cost, and schedule risks.
4. Assign categories such as Negligible, Marginal, or Critical.

Risk Projection
Risk projection estimates the impact of risks on a project using risk tables. Steps include:
1. Estimating probability (Li) and consequences (Xi).
2. Calculating impact.
3. Identifying high-impact and high-probability risks for action.

Risk Refinement
Refines risk impact through factors like nature, scope, and timing. Risk exposure is
calculated as RE = P * C, where P is probability and C is cost.

RMMM (Risk Mitigation, Monitoring, and Management)

Three components of RMMM:
1. Risk Avoidance: Proactive planning.
2. Risk Monitoring: Ensures risk aversion steps are followed.
3. Risk Management: Involves contingency planning and creating an RMMM Plan.
Quality Management
Focuses on minimizing variations in project outcomes and ensuring adherence to
specifications. It includes Quality of Design, Quality of Conformance, Quality Control, and
Quality Assurance.

Cost of Quality
1. Prevention Costs: Quality planning and training.
2. Appraisal Costs: Inspections and testing.
3. Failure Costs: Rework and repairs.
4. External Failure Costs: Customer support and warranty work.

Software Quality Assurance (SQA)

SQA activities ensure compliance with requirements, standards, and processes. They
include preparing SQA plans, conducting audits, and managing deviations.

Software Reviews and Formal Technical Reviews (FTR)

FTRs aim to identify errors early. Key steps include preparation, review meetings, and
reporting. They improve quality by detecting design flaws and ensuring requirements are
met.

Statistical Quality Assurance

Uses defect data to identify root causes and implement improvements. Six Sigma focuses on
defining, measuring, and analyzing defects to improve processes.

Software Reliability
Reliability measures the probability of failure-free operation. Metrics include:
1. MTBF: Mean Time Between Failures.
2. Availability: (MTTF / (MTTF + MTTR)) x 100%.

ISO 9000 Quality Standards

ISO 9000 provides guidelines for quality systems. Key types include:
1. ISO 9001: For design, development, and production.
2. ISO 9002: For production-only organizations.
3. ISO 9003: For installation and testing.

Certification stages include application, pre-assessment, document review, compliance

audit, registration, and continued inspection.