UNIT II - Software Processes
Software Processes
Software Engineering - ICS1204/IIT1204
Harare Institute of Technology
Three CASE Tools by Functionality
• CASE = Computer-Aided Software Engineering tools that automate/support software development
tasks.
• 1. DESIGN TOOLS - [Link] / Lucidchart
• Used to create UML diagrams: Use Case, Class, Sequence, Activity diagrams
• Helps in visual system design before coding begins
• 2. PROJECT MANAGEMENT TOOLS - JIRA / Trello
• Track tasks, sprints, bugs, and team assignments
• Supports Agile boards, backlogs, and progress reporting
• 3. TESTING TOOLS - Selenium / Postman
• Automate regression testing of web apps (Selenium) and APIs (Postman)
• Reduces manual testing effort and catches defects early
Functional vs Non-Functional Requirements
Functional Requirements Non-Functional Requirements
• Describe HOW WELL the system performs
• Describe WHAT the system must DO
• Quality attributes and constraints
• Specific behaviours and functions
• Example: 'The system must respond within 2
• Example: 'A user must be able to log in using a
seconds'
username and password'
• Example: 'The system must be available 99.9% of
• Example: 'The system shall send an email
the time'
notification when a result is uploaded'
• Categories: Performance, Security, Usability,
• Testable with pass/fail outcomes
Reliability, Scalability
Five Stages of the Waterfall Model
• The Waterfall Model is a sequential, linear process model - each phase must complete before the
next begins.
• 1. Requirements Analysis - Gather and document all system requirements from stakeholders
• Output: Software Requirements Specification (SRS) document
• 2. System Design - Translate requirements into architecture and detailed design
• Output: Design documents, data models, interface designs
• 3. Implementation (Coding) - Developers write source code based on design specs
• Output: Executable software components
• 4. Testing - Verify the system works correctly; find and fix defects
• Output: Test reports, defect logs
• 5. Maintenance - Deploy, support, and evolve the system post-delivery
• Output: Patches, updates, enhanced versions
Prototyping
• Prototyping:
• 1. Early Visibility - Client sees a working UI mockup early, reducing late requirement changes
• 2. Requirement Clarification - Vague requirements become concrete when client interacts with a
prototype
• 3. Expectation Alignment - Client sees realistic scope, preventing budget overruns from unrealistic
demands
• 4. Reduced Risk - Defects in UI logic are caught before expensive full development begins
• 5. Feedback Loop - Iterative refinement ensures the final product meets the client's actual vision
• Types: Throwaway prototype (exploratory) or Evolutionary prototype (refined into final product)
Scrum vs. Kanban
• Kanban
• Kanban Board provides a continuous visual flow of tasks (To Do → In Progress → Done)
• No fixed sprints - tasks flow based on team capacity and priority
• Work-in-Progress (WIP) limits prevent overloading any team member
• Ideal when task arrival is unpredictable and visual management is the priority
• Scrum
• Scrum uses fixed 2-week sprints with defined ceremony overhead (standups, retrospectives)
• More suited for teams with predictable backlogs and defined release cycles
Feasibility Study During Software Specification
• A Feasibility Study determines whether a proposed system is worth building before significant
resources are committed.
• Purpose: Avoid wasting time and money on unviable projects.
• 1. Technical Feasibility - Can we build it with current technology and skills?
• 2. Economic Feasibility - Does the benefit justify the cost? (Cost-Benefit Analysis)
• 3. Operational Feasibility - Will the system be accepted and used by end users?
• 4. Schedule Feasibility - Can it be delivered within the required timeframe?
• Output: A feasibility report recommending proceed, modify, or abandon the project
Top-Down vs Bottom-Up Integration
Top-Down Integration Bottom-Up Integration
• Start with the top-level module; stubs replace • Start with lowest-level modules; drivers simulate
lower modules upper modules
• Use when: High-level logic/control flow must be • Use when: Core/critical utility functions must be
tested first validated first
• Use when: Adding a new module to an existing • Use when: New module integrates at a lower
system from top layer level of an existing system
• Advantage: Early testing of overall system • Advantage: No stubs needed; real modules
architecture tested immediately
• Disadvantage: Stubs must be written; lower-level • Disadvantage: System-level behavior visible only
defects found late after all parts integrated