Unit 6: Software Process Model (10 Hours)

6.1 Software Project Concept

A software project is a complete set of activities required to develop a software product from its inception to its deployment and maintenance. It involves planning, defining scope, allocating resources, managing risks, and delivering a functional software solution within a specified timeframe and budget.

Definition of Software Project, Project vs Product

• Software Project: A temporary endeavor undertaken to create a unique software product, service, or result. It has a definite beginning and end, and is typically constrained by time, budget, and resources. Examples include developing a new mobile banking app, upgrading an existing enterprise resource planning (ERP) system, or creating a custom e-commerce platform.
• Project vs Product:
  • Project: A temporary undertaking to create a unique product, service, or result. It is finite, with a clear start and end.
  • Product: The tangible or intangible output of a project. It is enduring and continues to exist and evolve even after the project that created it has ended. A software product, once developed, can be used, sold, and maintained for a long period.

Project Scope, Objectives, Deliverables

• Project Scope: Defines the boundaries of the project, specifying what is included and what is excluded. It outlines the features, functions, and data that the software will encompass. A well-defined scope prevents "scope creep" (uncontrolled changes or continuous growth in a project's scope).
• Project Objectives: Specific, measurable, achievable, relevant, and time-bound (SMART) goals that the project aims to achieve. These might include delivering specific functionalities, improving system performance, reducing operational costs, or enhancing user experience.
• Deliverables: The tangible outputs or results produced during the project lifecycle. These can include requirement documents (e.g., SRS), design specifications, source code, test plans, user manuals, and the final executable software.

Stakeholders: Client, Developer, End User, Project Manager

• Client (Customer): The individual or organization funding the project and for whom the software is being developed. They define the requirements and ultimately accept the final product.
• Developer (Development Team): The team responsible for designing, coding, testing, and implementing the software. This includes software engineers, programmers, testers, and designers.
• End User: The individuals who will directly interact with and use the software once it is deployed. Their feedback is crucial for usability and functionality.
• Project Manager: The person responsible for planning, executing, and closing the project. They manage resources, budget, schedule, risks, and communication among all stakeholders to ensure project success.

6.2 Concept of Software Development Process

The software development process refers to the structured series of steps taken to develop a software product. It provides a framework for managing the complexity of software creation, ensuring quality, and meeting project goals.

Systematic Approach to Building Software

A systematic approach ensures that software development is not a chaotic activity but a well-organized and managed endeavor. It involves breaking down the complex task of software creation into smaller, manageable phases, each with specific goals, inputs, and outputs. This structured approach helps in improving predictability, control, and efficiency.

Activities: Planning, Analysis, Design, Coding, Testing, Maintenance

• Planning: Defining project goals, scope, resources, schedule, and budget. It involves feasibility studies, risk assessment, and establishing a project management plan.
• Analysis (Requirements Gathering): Understanding and documenting the needs of the client and end-users. This involves collecting, analyzing, and validating functional and non-functional requirements.
• Design: Translating the requirements into a detailed system architecture and component design. This phase determines how the software will be built, including data structures, algorithms, user interface, and system architecture.
• Coding (Implementation): Writing the actual source code based on the design specifications. This is where developers translate design into executable software.
• Testing: Verifying and validating that the software meets the specified requirements and is free of defects. This involves various levels of testing, such as unit, integration, system, and acceptance testing.
• Maintenance: Activities performed after the software has been deployed to ensure it continues to function effectively. This includes corrective maintenance (fixing bugs), adaptive maintenance (adapting to new environments), and perfective maintenance (enhancing features).

Process Models Guide the Sequence and Iteration

Software development process models (or SDLC models) provide a framework for these activities, guiding their sequence, iteration, and interdependencies. They define the workflow and how different phases interact, helping teams manage complexity and deliver quality software. Examples include Waterfall, Agile, and Prototyping models.

6.3 Concept of SDLC Life Cycle

The Software Development Life Cycle (SDLC) is a framework defining tasks performed at each step in the software development process. It's a structured approach that enables the production of high-quality, low-cost software in the shortest possible time.

Software Development Life Cycle Phases

A typical waterfall-style SDLC diagram depicts phases flowing sequentially downwards, where each phase must be completed before the next one begins. This linear progression emphasizes documentation and planning.

1. Requirement Analysis:
   • Inputs: Business needs, user expectations, existing system documentation.
   • Activities: Elicit, analyze, document, and validate requirements. Create a Requirements Specification Document (SRS).
   • Outputs: Software Requirements Specification (SRS) document, Use Case diagrams.
   • Example: Gathering detailed specifications for an online banking system, including user login, fund transfer, bill payment, and security protocols.
2. System Design:
   • Inputs: SRS document.
   • Activities: Define overall system architecture, database design, user interface design, module design, and low-level design.
   • Outputs: System Design Document (SDD), architectural diagrams (e.g., UML component, deployment diagrams), database schema.
   • Example: Designing the database schema for the banking system, defining API endpoints for transactions, and sketching the user interface layouts.
3. Implementation (Coding):
   • Inputs: SDD, detailed design specifications.
   • Activities: Write source code in chosen programming languages, unit testing of individual modules.
   • Outputs: Executable code, developed software modules, unit test reports.
   • Example: Programmers writing Java code for backend logic, HTML/CSS/JavaScript for the frontend, and integrating database connectivity.
4. Testing:
   • Inputs: Executable code, test plans, SRS, SDD.
   • Activities: Execute various test cases (unit, integration, system, acceptance), identify and report defects, retest after bug fixes.
   • Outputs: Test reports, defect logs, verified and validated software.
   • Example: Quality Assurance team performing functional tests, performance tests, security tests, and user acceptance tests on the banking application.
5. Deployment:
   • Inputs: Tested and approved software, deployment plan.
   • Activities: Install software in the production environment, configure servers, data migration, user training.
   • Outputs: Deployed software, user manuals, training materials.
   • Example: Releasing the banking application to live servers, making it accessible to actual customers, and providing support documentation.
6. Maintenance:
   • Inputs: Deployed software, user feedback, bug reports, change requests.
   • Activities: Correcting errors (corrective), adapting to new environments (adaptive), enhancing functionality (perfective), preventing future issues (preventive).
   • Outputs: Updated software versions, patches, performance improvements.
   • Example: Releasing updates to fix a security vulnerability, adding a new feature like QR code payments, or optimizing database queries for better performance.

6.4 System Analyst vs Software Engineer

While both roles are crucial in software development, they have distinct focuses and responsibilities.

System Analyst: Role, Skills, Responsibilities

• Role: A System Analyst acts as a bridge between business stakeholders (users, clients) and the technical development team. They understand business problems and translate them into technical requirements and system designs.
• Skills:
  • Strong analytical and problem-solving skills.
  • Excellent communication and interpersonal skills.
  • Business domain knowledge.
  • Requirements elicitation and documentation.
  • System modeling (e.g., use cases, data flow diagrams).
  • Basic understanding of software development technologies.
• Responsibilities:
  • Analyze existing systems and business processes.
  • Gather and document user requirements.
  • Design system solutions (high-level design).
  • Prepare feasibility studies and cost-benefit analysis.
  • Act as a liaison between users and developers.
  • Validate system solutions with stakeholders.

Software Engineer: Role, Skills, Responsibilities

• Role: A Software Engineer applies engineering principles to the design, development, testing, and maintenance of software systems. They are primarily focused on the technical implementation of solutions.
• Skills:
  • Proficiency in programming languages (e.g., Java, Python, C++).
  • Strong knowledge of data structures, algorithms, and software design patterns.
  • Understanding of operating systems, databases, and networking.
  • Problem-solving and debugging skills.
  • Experience with development tools, version control (e.g., Git), and testing frameworks.
  • Ability to write clean, efficient, and maintainable code.
• Responsibilities:
  • Design and develop software components and systems.
  • Write, test, and debug code.
  • Integrate software components.
  • Perform code reviews.
  • Maintain and upgrade existing software.
  • Collaborate with other engineers and architects.

Roles, Skills, Responsibilities Comparison

6.5 Requirement Collection Methods

Requirement collection, also known as requirement elicitation, is the process of gathering and understanding the needs and constraints of the stakeholders for a new software system.

• Interviews:
  • Description: Direct, face-to-face discussions with stakeholders to gather detailed information about their needs, expectations, and challenges.
  • Pros: Allows for clarification, probing, and observing non-verbal cues.
  • Cons: Time-consuming, potential for bias, and difficulty in scheduling.
• Questionnaires:
  • Description: A set of written questions distributed to a large number of stakeholders to gather quantitative or qualitative data.
  • Pros: Efficient for large groups, anonymous responses can encourage honesty.
  • Cons: Limited scope for follow-up, potential for misinterpretation of questions.
• Observation:
  • Description: Directly observing users performing their tasks in their natural work environment to understand current processes and identify pain points.
  • Pros: Provides realistic insights into user behavior and workflows, uncovers unstated requirements.
  • Cons: Users might alter behavior when observed (Hawthorne effect), time-consuming, requires trained observers.
• Document Analysis:
  • Description: Reviewing existing organizational documents such as reports, manuals, forms, policies, and system specifications to understand current processes and data.
  • Pros: Provides a rich source of historical data, reveals formal procedures, and can be done without direct user interaction.
  • Cons: Documents might be outdated, incomplete, or not reflect actual practices.
• Prototyping:
  • Description: Building a preliminary working model (prototype) of the software to demonstrate functionalities and gather feedback from users.
  • Pros: Helps visualize requirements, clarifies ambiguous needs, reduces risk of building the wrong product.
  • Cons: Users might expect the prototype to be the final product, can lead to uncontrolled iterations.
• Joint Application Development (JAD):
  • Description: A structured facilitated workshop session where key stakeholders (users, developers, analysts) come together to define and design the system collaboratively.
  • Pros: Accelerates requirement gathering, fosters strong collaboration, resolves conflicts quickly.
  • Cons: Requires significant planning, finding a suitable facilitator, and commitment from all participants.
• Requirements Specification Document (SRS):
  • Description: A formal, comprehensive document that describes all the functional and non-functional requirements of the software system. It serves as a contract between the client and the development team.
  • Key elements: Introduction, overall description, specific requirements (functional, non-functional, interface, performance, security), appendices.
  • Importance: Ensures common understanding, guides design and development, forms the basis for testing.

6.6 Concept of System Design

System design is the process of defining the architecture, modules, interfaces, and data for a system to satisfy specified requirements. It's about figuring out how the system will be built.

High-level Design (Architecture, Modules)

High-level design, also known as architectural design, focuses on the overall structure of the system. It defines the major components or modules of the system, their responsibilities, and how they interact with each other. It provides a blueprint for the entire system.

• Architecture: Defines the fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution. Examples include client-server, microservices, layered architecture.
• Modules: Breaking down the system into smaller, manageable, and logically independent units. Each module performs a specific function and interacts with other modules through well-defined interfaces.
• Example: For an e-commerce system, high-level design might identify modules like User Management, Product Catalog, Shopping Cart, Order Processing, and Payment Gateway, and define how they communicate.

Low-level Design (Detailed Algorithms, Data Structures)

Low-level design (LLD) focuses on the detailed internal logic of each module identified in the high-level design. It specifies how each component will work internally, including data structures, algorithms, and class designs.

• Detailed Algorithms: Step-by-step procedures for solving specific computational problems within a module.
• Data Structures: The way data is organized and stored to enable efficient access and modification (e.g., arrays, linked lists, trees, hash tables).
• Example: For the Order Processing module, LLD would specify the exact algorithm for calculating shipping costs, the data structure for storing order items, and the methods within the Order class.

Input/Output Design, Database Design

• Input/Output (I/O) Design:
  • Input Design: Focuses on how data is entered into the system. It aims to make data entry efficient, accurate, and user-friendly. This includes designing input forms, validation rules, and data capture methods.
  • Output Design: Focuses on how information is presented to the users. It aims to make output clear, meaningful, and useful. This includes designing reports, screens, dashboards, and error messages.
• Database Design:
  • Designing the logical and physical structure of the database that will store the system's data. This involves identifying entities, attributes, relationships, creating a schema, and normalizing tables to ensure data integrity and efficiency.
  • Example: Creating tables for Users, Products, Orders, and OrderItems with appropriate fields and primary/foreign keys.

UML Diagrams for Design

Unified Modeling Language (UML) is a standard language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. Various UML diagrams are used in system design:

• Use Case Diagram: Describes the functionality of a system from the user's perspective.
• Class Diagram: Shows the static structure of the system, including classes, their attributes, operations, and relationships.
• Sequence Diagram: Illustrates the interaction between objects in a sequential order, showing how operations are carried out.
• Component Diagram: Depicts the high-level organization of system components and their dependencies.
• Deployment Diagram: Shows the physical deployment of artifacts on nodes (hardware devices).
• Activity Diagram: Represents the flow of activities, similar to a flowchart.

6.7 Software and Quality

Software quality is crucial for user satisfaction, system reliability, and long-term success. It refers to the degree to which software possesses a desired combination of attributes.

Software Quality Attributes (ISO 9126)

The ISO/IEC 9126 standard defines six main quality characteristics for software products:

1. Functionality: The capability of the software product to provide functions which meet stated and implied needs when the software is used under specified conditions.
   • Sub-characteristics: Suitability, Accuracy, Interoperability, Security, Functionality compliance.
2. Reliability: The capability of the software product to maintain a specified level of performance when used under specified conditions.
   • Sub-characteristics: Maturity, Fault tolerance, Recoverability, Reliability compliance.
3. Usability: The capability of the software product to be understood, learned, operated, and attractive to the user.
   • Sub-characteristics: Understandability, Learnability, Operability, Attractiveness, Usability compliance.
4. Efficiency: The capability of the software product to provide appropriate performance, relative to the amount of resources used, under stated conditions.
   • Sub-characteristics: Time behavior, Resource utilization, Efficiency compliance.
5. Maintainability: The capability of the software product to be modified. Modifications can include corrections, improvements or adaptations of the software to changes in environment, and in requirements.
   • Sub-characteristics: Analyzability, Changeability, Stability, Testability, Maintainability compliance.
6. Portability: The capability of the software product to be transferred from one environment to another.
   • Sub-characteristics: Adaptability, Installability, Co-existence, Replaceability, Portability compliance.

Conceptual Formula for Quality: Quality = f(Functionality, Reliability, Usability, Efficiency, Maintainability, Portability)

Quality Assurance vs Quality Control

Quality Assurance (QA): A proactive process focused on preventing defects. It involves setting up processes, standards, and methodologies to ensure quality throughout the development lifecycle. QA is about "doing the right things to ensure quality."

Quality Control (QC): A reactive process focused on identifying and correcting defects. It involves activities like testing, inspections, and reviews of the software product to find bugs and verify compliance with requirements. QC is about "doing things right to check for quality."

In essence, QA is process-oriented and preventative, while QC is product-oriented and detective.

Testing Strategies for Quality

Testing is a critical part of quality control. Various strategies are employed:

• Unit Testing: Testing individual components or modules of the software in isolation. Performed by developers.
• Integration Testing: Testing the interaction and interfaces between integrated modules.
• System Testing: Testing the complete and integrated software system to verify that it meets all specified requirements. Includes functional, performance, security, and usability testing.
• Acceptance Testing: Formal testing conducted to determine if the system satisfies the acceptance criteria and enables the customer to determine whether to accept the system. Usually performed by end-users or clients.
• Regression Testing: Re-running previously passed tests after changes or additions to the software to ensure that new changes have not introduced new bugs or negatively impacted existing functionality.
• Performance Testing: Evaluating the system's responsiveness, stability, and scalability under various load conditions.
• Security Testing: Assessing the system's vulnerability to attacks and unauthorized access.

6.8 Software Development Models

Software development models, also known as SDLC models, provide a conceptual framework for managing software development projects. They dictate the sequence of phases and how they interact.

Waterfall Model

• Description: A linear, sequential approach where each phase (requirements, design, implementation, testing, deployment, maintenance) must be completed before the next one begins. There is typically no going back to a previous phase.
• Characteristics:
  • Documentation-heavy.
  • Phases are distinct and non-overlapping.
  • Progress flows downwards like a waterfall.
• Diagram Description: A series of boxes stacked vertically, with arrows pointing downwards from one box to the next, representing the sequential flow of phases: Requirements -> Design -> Implementation -> Testing -> Deployment -> Maintenance.
• Pros: Simple and easy to understand, clear milestones, good for stable requirements.
• Cons: Inflexible, difficult to accommodate changes, high risk if requirements are unclear, testing happens late in the cycle.
• Use Cases: Projects with very clear, stable, and well-understood requirements (e.g., government projects, embedded systems).

Prototype Model

• Description: Involves creating a working model (prototype) of the system early in the development process. This prototype is shown to the customer for feedback, which is then used to refine the requirements and subsequent prototypes until the final system is built.
• Characteristics:
  • Iterative feedback loop.
  • Early user involvement.
  • Focus on user interface and key functionalities in early stages.
• Diagram Description: A circular flow or loop involving: Requirements -> Quick Design -> Build Prototype -> Customer Evaluation -> Refine Requirements (loop back) -> Implement and Test Final System.
• Pros: Reduces risk of building the wrong product, early user involvement, handles unclear requirements well.
• Cons: Can lead to "throwaway" code, potential for scope creep, users might expect the prototype to be the final product.
• Use Cases: Projects with unclear or evolving user interface requirements, where user feedback is critical.

Agile Model

• Description: An iterative and incremental approach that emphasizes flexibility, customer collaboration, and rapid delivery of working software. It breaks down projects into small, manageable iterations called "sprints" (typically 2-4 weeks).
• Key Principles (from Agile Manifesto):
  • Individuals and interactions over processes and tools.
  • Working software over comprehensive documentation.
  • Customer collaboration over contract negotiation.
  • Responding to change over following a plan.
• Characteristics:
  • Short development cycles (sprints).
  • Daily stand-up meetings.
  • Continuous feedback and adaptation.
  • Cross-functional self-organizing teams.
• Diagram Description: A series of interconnected spirals or loops, each representing a sprint. Each sprint typically includes planning, requirements, design, development, testing, and review, leading to a potentially shippable product increment. The process repeats for subsequent sprints.
• Pros: High flexibility to change, early and continuous delivery, strong customer involvement, better quality through continuous testing.
• Cons: Requires active customer involvement, less documentation, can be challenging for large, distributed teams.
• Use Cases: Projects with rapidly changing requirements, start-ups, web development, mobile app development.

Comparison: Phases, Flexibility, Documentation, Customer Involvement, Use Cases