Software Engineering Fundamentals

Posted on May 28, 2024 in Other subjects

Software Engineering Resources

There are three major categories of software engineering resources:

  1. People
  2. Reusable software components
  3. Development environment (i.e., hardware and software tools)

People

  1. Project Planner: Begins by evaluating software scope and selecting the skills required for development.
  2. Team Composition: Both organizational position (e.g., manager, senior software engineer) and specialty (e.g., database, telecommunications, client/server) are specified. For smaller projects, a single individual may handle all tasks, consulting specialists when needed. Larger projects may involve geographically dispersed teams, requiring location specification for each member.
  3. Effort Estimation: Determining the number of people required depends on development effort estimation (e.g., person-months), which can be based on Lines of Code (LOC) or Function Points (FP).

Reusable Software Components

Component-Based Software Engineering (CBE) emphasizes reusability by creating and reusing building blocks called components. Types of components include:

  1. Off-the-shelf components (OTS Components)
  2. Full experience components
  3. Partial experience components
  4. New components

Development Environment

The Software Engineering Environment (SEE) includes hardware and software. Hardware provides a platform for tools used to create work products, which are the outcomes of good software engineering practices.

Software Architecture

Software architecture is the structure of a system, encompassing its components, their externally visible properties, and their interrelationships. The goal is to establish the system’s overall structure, linking design specifications to the actual design process.

Importance of Software Architecture

  1. Stakeholder Communication: Provides a representation of the system, enabling stakeholder participation and clearer requirement understanding.
  2. Early Decision-Making: Facilitates early design decisions, impacting system performance and operations.
  3. System Understanding: Offers a clear understanding of the system to be built.

Horizontal Partitioning

Horizontal partitioning divides the modular hierarchy into separate branches for each major program function (e.g., input, processing, output). Design-making modules reside at the top of the architecture.

Advantages

  1. Easy to test, maintain, and extend.
  2. Reduced side effects in change or error propagation.

Disadvantage

Increased data transfer across module interfaces, complicating program flow control.

Vertical Partitioning

Vertical partitioning distributes control and work top-down in the program structure.

Steps

  1. Create separate branches for each major function.
  2. Use control modules for inter-function communication.

Advantages

  1. Easy to maintain changes.
  2. Reduced change impact and error propagation.

Architectural Styles

  1. Data-Centered Architectures
  2. Data Flow Architectures
  3. Call and Return Architecture
  4. Object-Oriented Architecture
  5. Layered Architecture

Risk Management Strategies

Reactive Risk Strategy

  1. Corrective action is taken only when problems arise, often leading to”firefighting”
  2. Resources are allocated reactively, potentially jeopardizing the project if risks remain unmanaged.
  3. Lacks preventive measures, addressing risks only upon occurrence.
  4. Considered an outdated approach.

Proactive Risk Strategy

  1. Risk consideration begins before technical activities.
  2. Potential risks are identified, their probability and impact analyzed, and prioritized for management.
  3. Focuses on risk avoidance and efficient control mechanisms.
  4. Widely adopted in the IT industry as an intelligent approach.

Risk Characteristics

  1. Uncertainty: Risks may or may not occur.
  2. Consequences: Risks, when realized, lead to undesirable outcomes or losses.

Types of Risks

1. Project Risk

Impacts budget, schedule, staffing, resources, and requirements. Severe project risks can significantly increase project costs.

2. Technical Risk

Affects project quality and timeliness. Realized technical risks can lead to design, implementation, interface, verification, and maintenance issues. These risks arise when problems become increasingly difficult to solve.

3. Business Risk

Concerns the feasibility of the software product. Categories include:

  1. Market Risk: Lack of customer demand for a well-built product.
  2. Strategic Risk: Product misalignment with company business policies.
  3. Sales Risk: Uncertainty regarding product sales strategy.
  4. Management Risk: Departure of key personnel (e.g., senior management, responsible staff).
  5. Budget Risk: Depletion of the overall project budget.

Risk Mitigation

Risk mitigation focuses on preventing risks from occurring. Steps include:

  1. Communication with relevant staff to identify potential risks.
  2. Early identification and elimination of risk-causing factors.
  3. Developing organizational policies to ensure project continuity despite staff turnover.
  4. Maintaining team-wide awareness of current development activities.
  5. Timely and standardized documentation.
  6. Regular reviews to expedite work.

Risk Monitoring

Project managers monitor:

  1. Team behavior under project pressure.
  2. Teamwork effectiveness.
  3. Collaboration among team members.
  4. Emerging problems.
  5. Job availability within and outside the organization.

Objectives:

  1. Verify the occurrence of predicted risks.
  2. Ensure proper implementation of risk avoidance measures.
  3. Gather information for risk analysis.

Effective risk mitigation simplifies risk management when risks materialize.

Risk Management Plan (RMMM)

  1. Documents all risk analysis activities.
  2. May be integrated into the overall project plan or maintained separately.
  3. Individual risks can be documented using risk information sheets, potentially managed within database systems.
  4. Risk mitigation, monitoring, and analysis activities continue after documentation.

Software Configuration Management (SCM)

SCM encompasses activities for identifying, organizing, and controlling changes throughout the software lifecycle. It ensures quality improvement and error reduction by managing and controlling changes during development. SCM is a quality assurance activity applied throughout the software development process, focusing on managing evolving software systems.

Elements of a Configuration Management System

  1. Component Elements
  2. Process Elements
  3. Construction Elements
  4. Human Elements

SCM Repository

A software repository is a centralized information hub accessed by software engineers for making changes. Managed using database management functions, it ensures data integrity, sharing, integration, and maintains a uniform structure and format for software engineering work products.

Features of an SCM Repository

  1. Versioning
  2. Dependency Tracking and Change Management
  3. Requirements Tracing
  4. Configuration Management
  5. Audit Trails

Software Testing

Software testing is crucial for software quality assurance, serving as the final review of specification, design, and coding.

Objectives

–>1. Testing is a process of executing a program with the intend of finding an error. 2. A good test case is one that has high probability of finding an undiscovered error. 3. A successful test is one that uncovers an as-yet undiscovered error.

Top down testing is an incremental approach in which modules are integrated by moving down through the control structure. Modules subordinate to the main control module are incorporated into the system in either a depth first or breadth first manner. Integration process can be performed using following steps. 1. The main control module is used as a test driver and the stubs are substituted for all modules directly subordinate to the main control module. 2. Subordinate stubs are replaced one at a time with actual modules using either depth first or breadth first method. 3. Tests are conducted as each module is integrated. 4. On completion of each set of tests, another stub is replaced with the real module. 5. Regression testing is conducted to prevent the introduction of new errors.  

In bottom up integration the modules at the lowest levels are integrated at first, then integration is done by moving upward through the control structure. The bottom up integration process can be carried out using following steps.1. Low-level modules are combined into clusters that perform a specific software subfunction. 2. A driver program is written to co-ordinate test case input and output. 3. The whole cluster is tested. 4. Drivers are removed and clusters are combined moving upward in the program structure.