Cit831 Software Engineering

Unit 1: Software Engineering Methodology - Basic Notions

Examinable Points:
 Definition: Software engineering methodology - a framework for planning, developing,
and managing software.
 Software Engineering: systematic and measurable approach to software development,
operation, maintenance, and retirement.
 Software: computer programs, libraries, data, and documentation. Can be generic
(developed for a general market) or bespoke (custom-made).
 Attributes of Good Software:
o Operational: Budget, Usability, Efficiency, Functionality, Dependability, Security, Safety
o Transitional: Portability, Interoperability, Reusability, Adaptability
o Maintenance: Modularity, Maintainability, Scalability
 Distinguishing Software Types: Generic software is developed for a wide range of
users, while bespoke software is custom-made for a specific client.
Unit 2: Professional and Ethical Responsibilities
Examinable Points:
 Professional and Ethical Responsibilities: Software engineers have a duty to be
honest, ethical, and competent. Ethical behavior goes beyond just following the law.
 Areas of Professional Responsibility:
o Confidentiality: respecting client/employer confidentiality, even without a formal
agreement.
o Competence: not misrepresenting skills or taking on jobs outside expertise.
o Intellectual Property Rights: protecting intellectual property of employers and clients
(patents, copyrights, etc.).
o Computer Misuse: not using technical skills to misuse computers (e.g., playing games
on work computers, spreading viruses).
 IEEE-ACM Code of Ethics: Eight principles outlining expected ethical behavior:
o Public: Act in the public interest.
o Client and Employer: Act in the best interests of clients/employers, aligned with public
interest.
o Product: Ensure software meets the highest professional standards.
o Judgment: Maintain integrity and independence in professional judgment.
o Management: Promote ethical software development and maintenance practices.
o Profession: Uphold the integrity and reputation of the software engineering profession.
o Colleagues: Treat colleagues fairly and supportively.

1
o Self: Pursue lifelong learning and promote ethical practices.
Self-Assessment Tips:
 Identify the principle violated in the CEO scenario (likely Client and Employer or
Confidentiality).
 Recognize "commercial" is not one of the eight IEEE-ACM principles.
 Understand "confidentiality" as the relevant responsibility for protecting client
information.
Unit 3: Software Process Summary (Examinable Points)
1.0 Introduction
 This unit covers software processes and their activities.
2.0 Intended Learning Outcomes (ILOs)
 You should be able to describe the software process outline and its activities.
3.0 Main Content
 3.1 Software Process (SDLC)
o A well-defined sequence of stages for developing software.
 3.2 Process Activities
o Software Specification: Define what the system should do and its constraints. (Exam
Point)
o Software Development: Produce the software based on the specification. (Exam
Point)
o Software Validation: Ensure the software meets customer needs and functions as
specified. (Exam Point)
o Software Evolution: Adapt the software to changing user and work demands. (Exam
Point)
 3.3 Software Specification
o Defines required functionalities and development/operational limitations. (Exam Point)
 3.4 Software Development (Design and Implementation)
o Software Design: Create a software structure that fulfills the specification. (Exam
Point)
o Implementation: Translate the design into a working program. (Exam Point)
 3.5 Software Validation
o Ensures the software meets specifications and customer expectations. (Exam Point)
o Involves checking processes throughout development. (Exam Point)
 Testing Stages:
 Component Testing: Individual components are tested. (Exam Point)
 Integration Testing: Groups of components are tested together. (Exam Point)
2
 System Testing: Overall system functionality is tested. (Exam Point)
 3.6 Software Evolution
o Aims to implement major changes to the software. (Exam Point)
o Ensures system reliability and flexibility as it evolves. (Exam Point)
Discussion
 Difference between Software Process and Software Engineering Methodology
(Exam Point)
o Software Process: The general stages involved in software development.
o Software Engineering Methodology: Specific approaches to implementing the software
process (e.g., Waterfall, Agile).
 Scenario: Starting a Software Development Project (Exam Point)
o Begin by gathering requirements through software specification.
4.0 Self-Assessment Exercise
 Key: 1.a, 2.c, (These are the examinable points from the Self-Assessment Exercise)
5.0 Conclusion
 You learned about software processes and their activities.
6.0 Summary
 Software process activities include: Specification, Development, Validation, and
Evolution. (This is a general summary point)
Unit 4: Software Process Models - Summary of Examinable Points
Learning Outcomes:
 Define software process model
 Explain the waterfall model
 Distinguish between waterfall model and V-Model
Key Concepts:
 Software process model: A simplified representation of the software development
lifecycle.
Waterfall Model:
 First software process model.
 Sequential phases:
o Requirements analysis and definition
o System and software design
o Implementation and unit testing
o Integration and system testing
o Operation and maintenance
3
 Advantages:
o Well-defined stages.
o Easy to manage.
 Disadvantages:
o Inflexible - difficult to accommodate changes.
o Only suitable for projects with well-understood requirements.
V-Model:
 Improvement on waterfall model.
 Phases mirror waterfall model but with corresponding testing phases.
 Allows some parallel execution of activities.
 Advantages:
o More emphasis on testing throughout development.
 Disadvantages:
o Similar limitations to waterfall model regarding requirement changes.
When Waterfall and V-Model are Unsuitable:
 Requirements are not well-defined or likely to change.
 Project is complex or object-oriented.
 Long development cycles.
Self-Assessment Questions:
1. First software process model: Waterfall model (c).
2. Not a phase of waterfall model: Reverse engineering (b).
Unit 5: Evolutionary and Incremental Development
Learning Outcomes:
 Describe the objective of evolutionary development
 Outline the applications of evolutionary development
 Point out the advantages of incremental development
Evolutionary Development:
 Develops software iteratively with customer input.
 Starts with a basic outline and evolves based on feedback.
 Advantages:
o Flexible - adapts to changing requirements.
o Early user feedback.
 Disadvantages:
o Lack of process visibility.
4
o Systems can be poorly structured.
 Applications:
o Small/medium interactive systems.
o Parts of large systems (e.g., user interface).
o Short-lifetime systems.
Incremental Development:
 Delivers functionality in increments with prioritized requirements.
 Requirements for later increments can evolve.
 Advantages:
o Early delivery of customer value.
o Early prototypes for feedback.
o Lower project risk.
o More focus on testing high-priority features.
 Disadvantages:
o Requires good requirement prioritization.
When Evolutionary Development is Unsuitable:
 Large, complex software projects.
Self-Assessment Questions:
1. Works with customers to evolve a system: Evolutionary development (a).
2. Unsuitable for evolutionary development: Large long-lifetime system (d).
MODULE 2: INTRODUCTION TO SOFTWARE ENGINEERING METHODOLOGY
Unit 1: Prototyping
1.0 Introduction
This unit covers the prototyping model, its advantages and disadvantages.
2.0 Intended Learning Outcomes (ILOs)
 Describe the prototyping model.
 Understand the benefits of prototyping.
 Understand the problems of prototyping.
3.0 Main Content
 3.1 Prototyping Model
o Involves creating incomplete versions of the software to gather feedback and refine
requirements.
o Iterative process: Develop, test, refine based on user feedback.
o Benefits: Early user involvement, reduces ambiguity, improves communication.
5
 3.2 Types of Prototyping
1. Throwaway prototyping (Rapid Prototyping): Quick and simple model, discarded
later.
2. Evolutionary prototyping: Robust model that becomes part of the final system.
3. Incremental prototyping: Build the final product in separate prototypes, merged later.
3.3 Benefits of Prototyping
0. Early user feedback for better product.
1. Developer gains experience for a better final product.
2. Clarifies requirements and improves communication.
3. Increases chances of high-quality functionality with lower risk of failure.
3.4 Problems of Prototyping
0. Users may mistake the prototype for a finished product and expect immediate release.
1. Technical compromises during prototyping can lead to problems in the final system.
2. Budget may increase due to extended development time.
3. Not suitable for all projects (limited to heavy human-machine interaction, complex
output, new algorithms).
Discussion
 Describe the prototyping model (refer to section 3.1).
Scenario
As a team leader for a new software project with heavy human-machine interaction,
consider using the prototyping model because it allows for early user feedback to
improve the human-machine interface.
4.0 Self-Assessment Exercise
1. b. There is increased chance of having high quality functionality with low risks of
failure. (refer to section 3.3)
2. c. Budget may increase, as the management cost may go beyond the specified
limit. (refer to section 3.4)
5.0 Conclusion
This unit covered the prototyping model, its benefits (early feedback, improved
communication) and challenges (unrealistic user expectations, technical compromises,
increased budget).
6.0 Summary
Prototyping is valuable for early user involvement and reducing risks in software
development.
Summary of Unit 2: Spiral Development
Exam Points:

6
 Concept: Minimizes risks through prototypes and frequent reviews.
 Process: Iterative with risk assessment at each phase.
 Advantages:
o Adaptable to other models.
o Focuses on risk avoidance.
o Early attention to reusability.
o Continuous quality focus.
o Clear definition of objectives and constraints.
o Early error elimination.
o Includes maintenance as part of the process.
 Disadvantages:
o Relies on developer's risk assessment skills.
o Requires good documentation for non-experts.
o Lacks detailed process steps.
o Relatively new, with limited experience.
Self-Assessment Questions:
 Spiral development includes maintenance as a cycle (b).
 Risk analysis is constantly done in spiral development (a).
Summary of Unit 3: Agile Development Methods
Exam Points:
 Concept: Responds to changing requirements through short iterations.
 Manifesto Values:
o Individuals and interactions over processes and tools
o Working software over comprehensive documentation
o Customer collaboration over contract negotiation
o Responding to change over following a plan
 Principles: (all 12 principles are examinable)
o Focus on customer satisfaction through early and continuous delivery.
o Welcome changing requirements even late in development.
o Deliver working software frequently (weeks, not months).
o Close, daily cooperation between business people and developers.
o Build projects around motivated individuals.
o Face-to-face communication is the best form of communication.
o Working software is the primary measure of progress.
7
o Maintain a sustainable development pace.
o Continuously focus on technical excellence and good design.
o Simplicity is essential.
o Best architectures, requirements, and designs emerge from self-organizing teams.
o Regularly reflect on becoming more effective and adjust accordingly.
 Applications:
o Small/medium product development.
o Custom product development with client involvement.
 Problems:
o Not suitable for complex or embedded systems.
o Incompatible with large-scale, legal contracts.
o Not ideal for software maintenance (most software costs).
o Designed for small, co-located teams (may not work for distributed teams).
 Agile Models (all are examinable):
o Dynamic Systems Development Method (DSDM)
o Extreme Programming (XP)
o Scrum
o Rapid Application Development (RAD)
Self-Assessment Questions:
 Spending time on specification and documentation is not an Agile principle (c).
 V-model is not an Agile development model (c).
Unit 4: Extreme Programming (XP)
Examinable Points:
 Concept: Extreme Programming (XP) is an Agile methodology for software
development that emphasizes responsiveness to changing requirements and improved
software quality through short development cycles and frequent releases.
 Techniques:
o User stories: Define requirements as scenarios experienced by users.
o Refactoring: Continuously improve software design by making small changes.
o Test-driven development (TDD): Write unit tests before coding to ensure functionality.
o Pair programming: Programmers work in pairs to improve code quality and knowledge
sharing.
 Criticisms:
o Insufficient design documentation.

8
o Difficulty in fixed-cost contracts.
o Potential inefficiency for large projects.
Self-Assessment Questions:
 Question 1: Identify the non-XP technique (d. Specification).
 Question 2: Identify how XP captures requirements (a. User stories).
Unit 5: The Dynamic System Development Method (DSDM)
Examinable Points:
 Concept: DSDM is an Agile methodology that focuses on rapid application
development with a disciplined approach. It emphasizes the full project lifecycle.
 Phases:
o Feasibility study: Assess project viability.
o Business study: Define business needs and requirements.
o Functional model iteration: Develop a functional model of the system.
o Design and build iteration: Design and build the system incrementally.
o Implementation: Implement the complete system.
 Principles:
o Focus on the business need.
o Deliver on time.
o Collaborate among stakeholders.
o Never compromise quality.
o Build incrementally.
o Develop iteratively.
o Communicate continuously.
o Demonstrate control of the project.
 Techniques:
o Prototyping: Develop early prototypes for user feedback.
o Timeboxing: Break down the project into fixed-time increments.
o Testing: Conduct testing throughout each iteration.
o Workshops: Facilitate communication and requirement gathering.
o Modeling: Visually represent the system and business domain.
o Configuration management: Manage all project deliverables.
 Roles:
o Executive sponsor: Provides funding and makes key decisions.
o Visionary: Initiates the project and ensures alignment with business goals.
9
o Project manager: Manages the overall development process.
o Facilitator: Leads workshops and keeps the team motivated.
o Technical coordinator: Designs the system architecture and ensures technical quality.
o Ambassador user: Represents user needs and provides feedback.
o Advisor user: Provides daily user insights.
o Team leader: Leads the development team.
o Solution developer: Analyzes requirements, models the system, and writes code.
o Solution tester: Tests the system functionality.
o Scribe: Documents workshop discussions, decisions, and agreements.
Self-Assessment Questions:
 Question 1: Identify the non-DSDM technique (c. Requirements engineering - This is a
broader concept than a specific DSDM technique).
 Question 2: Identify the role with ultimate budget approval power (a. Executive
sponsor).
MODULE 3: REQUIREMENT ENGINEERING PROCESS
Unit 1: Requirements
Examiner points:
 Requirements definition: descriptions of the services provided by a system and the
constraints on its operation.
 Requirements imprecision: requirements may not be completely precise due to serving
a dual function - for bidding and for contract.
 Types of requirements:
o User requirements: high-level abstract requirements in natural language.
o System requirements: more detailed descriptions of the system's functions and
constraints.
o Functional requirements: what the system should do.
o Non-functional requirements: constraints on the system such as performance or
security.
o Domain requirements: requirements specific to the application domain.
 Completeness and consistency of requirements: Ideally, requirements should be
complete (include everything) and consistent (not contradict each other). In practice,
this is difficult to achieve.
Self-assessment exercise answers:
1. b. Requirements
2. c. Operational (not a standard type)

10
 Unit 2: Functional and Non-Functional Requirements
 Functional Requirements:
o Define functionality (system services, behavior).
o Examples (Learning Management System example in Figure 3.3).
o Levels:
 Functional User Requirements (high-level, natural language).
 Functional System Requirements (detailed, developer-oriented).
 Non-Functional Requirements:
o Define and differentiate from functional requirements.
o Classifications (Figure 3.4):
 Product Requirements (execution speed, reliability).
 Organizational Requirements (process standards).
 External Requirements (interoperability, legislation).
o Challenges:
 Measurable goals vs. vague requests.
 Defining metrics (Table 3.1).
 Self-Assessment Questions:
o Identify functional requirement type (Q1: answer a).
o Identify non-functional requirement (Q2: answer a).
Additional Notes:
 Non-functional requirements can be critical for system usability.
 Developers and stakeholders should agree on measurable goals for non-functional
requirements.
Scenario:
 Lead a team to document requirements for online marketplace software.
 Identify two possible functional system requirements (e.g., user registration, product
search).
Unit 3: Domain Requirements
Examinable Points:
 Definition: Domain requirements come from the system's application domain and
describe its characteristics and features reflecting that domain.
 Examples:
o New functionalities (e.g., specific calculations in a finance system)
o Constraints on existing requirements (e.g., library system limiting loan duration)

11
o Rules on operation execution (e.g., specific steps for processing an order)
 Importance: Domain requirements are crucial to avoid building unusable systems.
 Problems:
o Understandability: Domain language might be unfamiliar to software engineers.
o Implicitness: Domain experts might not explicitly state all requirements due to their
deep understanding of the field.
Self-Assessment Questions:
1. Answer: a. domain requirement (Identifies the source and purpose of domain
requirements)
2. Answer: d. domain requirements are not as important as functional requirements (All
are important, but domain requirements define the system's purpose)
Key Takeaways:
 Clear understanding of domain requirements is vital for system development.
 Communication between domain experts and software engineers is crucial to capture all
requirements explicitly.
Unit 4: Requirements Design and Writing Summary
Examinable Points:
 Guidelines for Writing Requirements:
o Use a standard format or template.
o Be consistent in language ("shall" for mandatory, "should" for desirable).
o Highlight key parts of the requirement.
o Avoid computer jargon and ambiguity.
o Use simple and direct sentences.
o Separate requirements from design.
 System Requirements:
o More detailed specifications of functionalities, services, and constraints than user
requirements.
o Basis for designing the system and may be included in the system contract.
 The Requirements Document:
o Official statement of what is required of the system developers.
o Includes user and system requirements.
o Defines WHAT the system should do, not HOW.
 Users of a Requirements Document:
o System Customers: Specify and confirm requirements, propose changes.
o Managers: Plan bids and development processes.
12
o System Engineers: Understand the system to be developed.
o System Test Engineers: Develop and implement validation tests.
o System Maintenance Engineers: Understand the system and its components.
 User Requirements:
o Describe functional and non-functional requirements in a user-friendly way.
o Defined using natural language, tables, and diagrams.
 IEEE Requirements Standards:
o A generic standard for organizing requirements documents (introduction, description,
requirements, appendices, index).
Self-Assessment Exercise Answers:
1. c. use professional jargons (This is not a guideline; avoid jargon for clarity.)
2. b. Functional (These specify the services delivered by the system.)
Scenario Answer:
No, the note of requirements might not be enough for technical design. Requirements
need to be clear, complete, and unambiguous. The note might lack details, have
missing information, or be poorly written.
Additional Notes:
 The unit emphasizes the importance of clear, concise, and well-structured requirements
documents.
 Understanding different user types and their needs for the requirements document is
crucial.
Unit 5: Requirement Elicitation and Analysis Summary
Exam Points:
 Requirements Engineering Processes:
o Define requirements engineering (RE). (Sec 3.1)
o Describe the iterative and interleaved nature of the RE process. (Sec 3.1)
o List the common activities of the RE process. (Sec 3.1)
 Requirements elicitation and analysis
 Requirements specification
 Requirements validation
 Requirements Elicitation and Analysis:
o Explain the purpose of requirements elicitation and analysis. (Sec 3.2)
o Identify stakeholders involved in requirements elicitation. (Sec 3.2)
 Software engineers
 Clients (stakeholders)
13
 System users (stakeholders)
 Requirements Elicitation and Analysis Process:
o Describe the activities involved in the requirements elicitation process. (Sec 3.3)
 Requirements discovery and understanding (gathering)
 Requirements classification and organization
 Requirements prioritization and negotiation
 Requirements documentation
 Challenges of Requirements Elicitation:
o Explain the challenges of eliciting requirements from stakeholders. (Sec 3.4)
 Stakeholders may not know or have difficulty articulating their needs.
 Stakeholders may use domain-specific language.
 Conflicting requirements from different stakeholders.
 Changing requirements and emergence of new ones.
Self-Assessment Exam Answers:
1. e. Requirements validation (This is part of a separate process)
2. d. Requirements documentation (This can be part of both elicitation and specification)
MODULE 4: REQUIREMENTS ENGINEERING PROCESSES
Unit 1: Requirements Elicitation - Observation
Exam Points:
 Requirements elicitation techniques: involve gathering information from stakeholders
about a proposed system. This can be done through meetings, interviews, document
analysis, and observation.
 Observation: a technique where the requirements engineer watches stakeholders
perform their tasks to understand how they use the existing system and how they might
use the new system.
 Effectiveness of Observation:
o Helps discover implicit requirements based on how people actually work, not just formal
processes.
o Reveals requirements related to cooperation and awareness of others' activities.
 Shortcomings of Observation:
o Doesn't support innovation, limited to understanding existing systems.
o Not effective for broader organizational or domain requirements (focuses on end-users).
Self-Assessment Questions:
1. Answer: b. interviewing (Exam Point: Basic ways of gathering information)
2. Answer: b. observation (Exam Point: Effectiveness of Observation)
14
 Unit 2: Requirements Elicitation - Interviewing
Exam Points:
 Interviewing: a technique where the requirements engineer asks stakeholders
questions about the system to gather information.
 Types of Interviews:
o Closed interview: uses pre-defined questions for specific answers.
o Open interview: explores a wider range of issues with no set agenda.
 Interviews in Practice:
o Usually a mix of closed and open-ended questions.
o Good for understanding stakeholder activities and system interaction.
o Limited in understanding domain requirements due to terminology and implicit
knowledge.
 Effective Interviewers:
o Open-minded and willing to listen without preconceived ideas.
o Use prompts and proposals to encourage detailed responses.
Self-Assessment Questions:
1. Answer: b. observation (Exam Point: Basic ways of gathering information)
2. Answer: a. open (Exam Point: Types of Interviews)
Unit 3: Requirements Analysis - Viewpoints
Exam Points:
 Concept of Viewpoints: Viewpoints are a way to organize requirements by
representing the perspectives of different stakeholders in a system.
 Types of Viewpoints:
o Interactor Viewpoints: People or systems that directly interact with the system (e.g.,
customer for an ATM).
o Indirect Viewpoints: Stakeholders who influence the system but don't directly use it
(e.g., bank management for an ATM).
o Domain Viewpoints: Characteristics and constraints that affect the system (e.g.,
communication standards for an ATM).
 Viewpoint Identification Techniques:
o Providers and receivers of system services.
o Systems interacting directly with the specified system.
o Regulations and standards.
o Sources of business and non-functional requirements.
o System engineers for development and maintenance.

15
o Marketing and other business viewpoints.
Self-Assessment Questions:
 Question 1: The answer is a. Domain. Domain is a type of viewpoint, not application,
direct, or analysis.
 Question 2: The answer is c. knowing the data gathering approach to use. Data
gathering is a technique, not a method for identifying viewpoints.
Unit 4: Requirements Specification
Exam Points:
 Requirements Specification: The process of writing user and system requirements in
a document.
 Properties of a Specification Document:
o Clear, consistent, and complete requirements to avoid conflicts.
o Describes external system behavior and constraints only.
o No details on system architecture, design, or implementation.
o Uses natural language, tables, forms, and diagrams (avoid jargon).
 Ways of Writing System Specifications:
o Natural Language: Simple sentences, but can be vague and ambiguous.
o Structured Natural Language: Uses templates for each requirement with specific
information fields.
o Graphical Notations: Uses models (e.g., UML diagrams) with text annotations for
clarity.
o Mathematical Specifications: Reduces ambiguity but may be difficult for customers to
understand.
Self-Assessment Questions:
 Question 1: The answer is c. Low-level language. Low-level language is for
programming, not requirements specification.
 Question 2: The answer is (multiple possible answers): a. Graphical notations, b.
Structured natural language. Both graphical notations and structured natural
language can help reduce ambiguity.
Unit 5: Requirements Validation Summary
Examinable Points:
 Requirements Validation:
o Definition: Ensuring requirements define the system the customer wants.
o Importance: Reduces costs of fixing errors later in development.
 Requirements Checking:
o Validity: Meets customer needs.

16
o Consistency: No conflicts between requirements.
o Completeness: Includes all necessary functions.
o Realism: Feasibility with budget and technology.
o Verifiability: Can be tested.
 Requirements Validation Techniques:
o Reviews: Systematic analysis by a team to find errors and inconsistencies.
o Prototyping: Using a model to check if requirements meet expectations.
o Test-case generation: Developing tests to check testability of requirements.
 Requirements Change and Reviews:
o Reasons for Change:
 Changing environment.
 Different needs of stakeholders (initiators vs. end-users).
 Conflicting requirements from different stakeholders.
o Importance of Reviews: Catch errors and inconsistencies early.
 Requirements Management Planning:
o Key Considerations:
 Requirement identification and cross-referencing.
 Change management process.
 Traceability policies.
 Tool support (e.g., requirements management systems).
 Requirements Change Management:
o Purpose: Control changes and ensure they are worthwhile.
o Process Stages:
 Problem analysis and change specification.
 Change analysis and costing.
 Change implementation (updating requirements document).
 Self-Assessment Questions:
o Identify the non-existent requirements validation technique (answer: c. Automatic
review).
o Recognize requirements management planning as the process for handling changing
requirements (answer: c. Requirements management planning).
MODULE 5: SOFTWARE ENGINEERING
Unit 1: System Modeling
Examiner points:

17
 System Modeling:
o Definition: developing abstract models of a system to represent different perspectives
o Techniques: graphical notations (UML), formal models (mathematical expressions)
 Relevance of System Modeling:
o Understanding system functionality
o Communication with stakeholders (customers)
o Different model types for different perspectives:
 External perspective (context)
 Behavioral perspective
 Structural perspective (data architecture)
 Model Types:
o Data processing model
o Composition model
o Architectural model
o Classification model
o Stimulus/response model
 Context Models:
o Show operational context (outside system boundaries)
o Social and organizational factors affecting boundaries
o Architectural models show system relationship with other systems
 Process Models:
o Overall process and supported processes
o Data flow models: processes and information flow
 Behavioral Models:
o Overall system behavior
o Types:
 Data processing models (data movement through the system)
 State machine models (system response to events)
 Data Processing Models:
o Data flow diagrams (DFDs): processing steps and data flow
o Advantages of DFDs: simple notation, customer understandable, end-to-end view
 Application of Data Flow Diagrams:
o Functional perspective
o Data tracking and system understanding
18
o Data exchange between a system and its environment
Self-Assessment Exercise Answers:
1. c. Implementation model (not a type of system modeling)
2. a. graphical notation and formal model
Unit 2: Formal Methods Summary
Exam Points:
 Definition: Formal methods are mathematical approaches to software development
using a formal model to find errors (3.1).
 Process:
o Translate user requirements into a mathematical model (3.1).
o Analyze the model to find inconsistencies (3.1).
 Types of Formal Methods:
o Formal specification (3.1)
o Specification analysis and proof (3.1)
o Transformational development (3.1)
o Program verification (3.1)
 Formal Specification: Unambiguous description of what the system should do (3.2).
 Benefits of Formal Specification:
o Deep understanding of requirements (3.4.1).
o Easy analysis to discover inconsistencies (3.4.2).
o Reduced program testing costs (3.4.3).
o Removes inconsistencies (3.4.4).
 Reasons for Lower Adoption:
o Increased focus on time-to-market over quality (3.5).
o Difficulty applying to user interfaces (3.5).
o Challenges scaling to large systems (3.5).
 Use Cases: Best suited for critical systems with high failure costs (3.6).
Self-Assessment Exercises:
1. Which of these is not a formal method?
o Answer: c. agile development (4.1)
2. What is the principal benefit of formal methods?
o Answer: a. reduced number of faults (4.2)
Conclusion:

19
 Formal methods offer advantages but haven't been widely adopted due to limitations
(6.0).
UNIT 3: ARCHITECTURAL DESIGN AND MODELS
Architectural Design
 What it is: The process of designing a system's organization to meet its functional and
non-functional requirements. This involves defining the system's sub-systems, major
components, and the way they interact and communicate.
 Why it's important: Architectural design is an early stage that sets the foundation for
the entire design process. It bridges the gap between specifying the system and
designing it.
Software Architecture
 Essentially: The system's fundamental structure, resulting from the architectural design
process.
Architectural Models
 Purpose: Document an architectural design.
 Types:
o Static structural model: Shows the system's major components.
o Dynamic process model: Shows how processes are structured within the system.
o Interface model: Defines how sub-systems interact with each other.
o Relationships model (e.g., data-flow model): Shows how sub-systems are connected.
o Distribution model: Shows how sub-systems are spread across different computers.
Architectural Design Decisions
 In essence: A creative process that varies depending on the system being built.
 Common decisions:
o Is there a generic application architecture suitable for this system?
o How will the system be distributed (e.g., centralized, client-server)?
o What architectural styles are appropriate (e.g., layered, service-oriented)?
o How will the system be structured (e.g., modular, object-oriented)?
o How will the system be broken down into modules?
o What control strategy should be used (e.g., centralized, distributed)?
o How will the design be evaluated?
o How will the architecture be documented?
Examinable Points
 Definition of architectural design
 Definition of software architecture

20
 Different architectural models and their purposes
 Common architectural design decisions
Unit 4: Sub-Systems and Modules
Sub-systems:
 A sub-system is a self-contained system capable of independent operation without
relying on other sub-systems.
Modules:
 A module is a component within a system that provides services to other components
but isn't considered a separate system itself.
Modular Decomposition:
 This process breaks down sub-systems into smaller, more manageable modules.
Modular Decomposition Models:
 Object Model: The system is decomposed into interacting objects.
 Pipeline/Data-Flow Model: The system is decomposed into functional modules that
transform inputs into outputs.
Self-Assessment Questions:
 Question 1: The answer is a. A module. (Identifies the definition of a module)
 Question 2: The answer is a. modular decomposition. (Identifies the process of
breaking down sub-systems)
Key takeaway:
 This unit focuses on understanding how complex systems can be built from
independent sub-systems and smaller, functional modules. Modular decomposition
helps achieve this by breaking down larger systems into manageable pieces.
Examinable Points in Unit 5: Software Design
1. Software Design Concepts:
 Definition: Software design is the process of planning and problem-solving to create a
software solution that meets specified requirements.
2. Design Stages:
 A. Problem Understanding: Analyze the problem from various perspectives to identify
design requirements.
 B. Solution Identification: Evaluate potential solutions and select the most suitable one
based on experience and available resources.
 C. Solution Abstraction: Describe the design components using graphical, formal, or
other descriptive notations.
 D. Iterative Process: Repeat the process for each identified abstraction.

21
 3. Design Phases:
 i. Architectural Design: Identify subsystems within the software.
 ii. Abstract Specification: Define the functionalities of each subsystem.
 iii. Interface Design: Specify how subsystems interact with each other.
 iv. Component Design: Break down subsystems into smaller, manageable components.
 v. Data Structure Design: Design data structures to store and manage problem data.
 vi. Algorithm Design: Design algorithms to perform specific functions within the
software.
4. Top-Down Design Technique:
 Key principle: Start with the highest-level components and gradually decompose them
into lower-level details.
 Practical considerations: Real-world large systems often involve a mix of top-down and
bottom-up approaches. Designers leverage experience and potentially existing
components throughout the process.
5. Design Strategies:
 i. Functional Design:
o Focuses on functionalities of the system.
o Centralized system state shared between functions operating on it.
 ii. Object-Oriented Design:
o Views the system as a collection of interacting objects.
o Decentralized system state with each object managing its own data.
o Objects communicate through methods and can be instances of classes.
6. Self-Assessment Questions:
 Q1: Top-down design approach (c).
 Q2: Object-oriented design (a).
MODULE 6: SOFTWARE ENGINEERING
Summary of Unit 1: Software Testing
Key Concepts:
 Verification and Validation (V&V): The process of checking that software meets
specifications and fulfills its intended purpose.
o Verification: Ensures the software is built correctly according to requirements (low-
level check). Done through static testing (code reviews).
o Validation: Ensures the software meets user expectations (high-level check). Done
through dynamic testing and user reviews.
 Testing Stages: The different stages of software testing:
o Unit testing: Individual components
22
o Module testing: Groups of dependent components
o Sub-system testing: Integrated modules into subsystems
o System testing: Complete system before delivery
o Acceptance testing: User testing to confirm requirements are met
Exam Points:
 The difference between verification and validation.
 The purpose of software inspections (discovering defects).
 The distinction between testing and debugging (testing finds errors, debugging fixes
them).
 The different stages of software testing.
Self-Assessment Questions:
 Which option checks if the software meets requirements (verification)? (c) verification
 What is concerned with locating and repairing errors (debugging)? (b) debugging
Summary of Unit 2: Software Inspection
Key Concepts:
 Software Inspection: A process where people examine software artifacts (code,
requirements) to find defects.
 Inspection Pre-conditions: Necessary conditions for effective inspections:
o Precise specification
o Familiar team members
o Syntactically correct code
o Error checklist
o Management buy-in (costs, non-punitive)
 Inspection Checklists: Lists of common errors to guide inspections (programming
language dependent).
Exam Points:
 Software inspections do not require code execution.
 Inspections complement testing (find different types of errors).
 Error checklists are programming language dependent.
Self-Assessment Questions:
 Which statement about inspections is correct? (a) Software inspection does not require
execution of a system
 What involves examining code for defects? (a) Software Inspection

23
 Summary of Unit 3: Software Reliability
Key Concepts:
 Software Dependability: The degree to which software can be relied on. Critical
applications require high dependability.
 Fault Minimisation: Techniques to reduce the number of software faults.
 Fault-Free Software: Software that conforms to its specification (may still have errors
due to faulty specifications). It's expensive to achieve.
 Reliable Software Processes: Well-defined, repeatable software development
processes that minimize faults (include V&V).
Exam Points:
 Not all software needs high dependability.
 Fault-free software can still be incorrect.
 Reliable processes minimize faults through V&V.
Self-Assessment Questions:
 Which applications require high dependability? (d) critical applications
 What kind of software conforms to its specification? (a) fault-free software
Software Re-use (Unit 4): Examinable Points
Concept:
 Software re-use is the practice of using existing software components in new
applications.
 It's like using pre-built components (like Lego bricks) to create new systems instead of
building everything from scratch.
Benefits:
 Increased reliability: Reused components have likely been tested and debugged in
other systems, making them more reliable.
 Reduced process risk: Development costs are more predictable because reusing
components avoids the uncertainties of entirely new development.
 Effective use of specialists: Focuses development effort on customizing existing
components rather than training new developers on every project.
 Standards compliance: Reusable components can embed coding standards and best
practices.
 Accelerated development: Saves time by avoiding original development for common
functionalities.
Requirements:
 Reusable component availability: A component library or database for easy discovery of
suitable components.

24
 Component understanding: Developers need to understand how components work and
if they meet their needs.
 Component documentation: Clear documentation on how to reuse components and
potential associated costs.
Development for Re-use:
 Existing components may need modification to be usable in different contexts.
 Requires a specific development process to generalize and document components for
broader reusability.
Software Evolution and Maintenance (Unit 5): Examinable Points
Concept:
 Software evolution is the process of adapting software to meet changing needs over
time.
 Software needs to evolve to accommodate new user requirements, business needs,
and technological advancements.
Activities:
 Change analysis: Understanding the proposed changes and their impact.
 Release planning: Planning how to release the updated software.
 System implementation: Making the necessary changes to the current software.
 Release: Delivering the updated software to users.
Software Maintenance:
 The process of modifying a software system after it's been delivered.
 Includes fixing errors, adding new features, or adapting to new environments.
Types of Maintenance:
 Corrective: Fixing bugs and vulnerabilities in the software.
 Adaptive: Modifying the software to work in new environments or with new technologies.
 Perfective: Adding new features or functionalities to the software.

25