Lesson 1

Applying the Systems Development Life Cycle (SDLC) to aircraft systems like the Boeing 737 involves adapting its phases, namely 1) planning, 2) analysis, 3) design, 4) implementation, 5) testing, and 6)maintenance to the unique complexities of aerospace engineering. Aircraft systems integrate hardware (e.g., avionics, engines, flight controls) and software (e.g., flight management systems), so the SDLC must align with rigorous safety, regulatory, and performance standards like those from the FAA (Federal Aviation Administration) or EASA (European Union Aviation Safety Agency). Here’s how it can be applied:

1. Planning
   • Objective: Define the scope, goals, and feasibility of the aircraft system or upgrade (e.g., a new avionics suite for the 737).
   • Application: Engineers and stakeholders (e.g., Boeing, airlines, regulators) identify requirements like fuel efficiency, passenger capacity, or compliance with airworthiness directives. For instance, the 737 MAX’s Maneuvering Characteristics Augmentation System (MCAS) would have started with planning to enhance stall prevention.
   • Key Activities: Risk assessment (e.g., safety-critical failures), cost estimation, and scheduling. Regulatory standards like DO-178C (for software) or DO-254 (for hardware) are considered early.
2. Analysis
   • Objective: Gather and refine detailed requirements.
   • Application: For the 737, this might involve analyzing aerodynamic performance, pilot interface needs, or sensor integration for systems like MCAS. Input from pilots, maintenance crews, and regulators ensures all operational and safety needs are captured.
   • Key Activities: Requirements traceability to ensure every feature (e.g., autopilot behavior) meets a specific need. Failure modes and effects analysis (FMEA) might be used to anticipate issues like sensor malfunctions.
3. Design
   • Objective: Create blueprints for the system.
   • Application: Engineers design the 737’s subsystems, i.e., flight control software, hydraulic actuators, or engine interfaces. For MCAS, this meant specifying how angle-of-attack sensors would trigger control surface adjustments.
   • Key Activities: Model-based design (e.g., using simulations of flight dynamics), redundancy planning (e.g., dual sensors), and compliance with standards. Iterative prototyping might simulate 737 flight conditions.
4. Implementation
   • Objective: Build and integrate the system.
   • Application: Software is coded (e.g., MCAS algorithms), hardware is manufactured (e.g., actuators), and subsystems are integrated into the 737 airframe. This phase includes rigorous version control to track changes across thousands of components.
   • Key Activities: Assembly of physical aircraft systems, software integration, and initial bench testing. For the 737 MAX, this would involve linking MCAS to the flight control computer.
5. Testing
   • Objective: Verify and validate the system against requirements.
   • Application: The 737 undergoes extensive testing, whcih consist of unit tests (e.g., sensor accuracy), integration tests (e.g., MCAS with stabilizers), and system-level tests (e.g., full flight simulations). Flight testing in real-world conditions (e.g., high-altitude stalls) is critical.
   • Key Activities: Compliance with certification tests (e.g., FAA’s Transport Airplane Directorate protocols). The 737 MAX’s MCAS issues highlight the importance of edge-case testing (e.g., single sensor failure), which was initially underexplored.
6. Maintenance
   • Objective: Deploy, monitor, and improve the system over its lifecycle.
   • Application: After certification, the 737 enters service. Maintenance includes software updates (e.g., post-MCAS fixes in 2019), hardware inspections, and retrofits. Airlines report issues via systems like the Aviation Safety Reporting System, feeding back into upgrades.
   • Key Activities: Continuous monitoring (e.g., via flight data recorders), patch deployment, and lifecycle management. For the 737, this might mean adapting systems to new regulations or operational feedback over decades.

In practice, Boeing might use a tailored SDLC variant like the V-Model (emphasizing verification and validation at each step) or integrate it with Model-Based Systems Engineering (MBSE) to simulate the 737’s behavior digitally before physical builds. The MCAS saga showed that skipping thorough analysis or testing can have catastrophic consequences, reinforcing the SDLC’s value in such high-stakes domains. Would you like me to dive deeper into a specific phase or example, like the 737 MAX’s development challenges?

New books and articles are appearing on analysis patterns and refactoring the development process. Analysts are recognizing that our development processes need to support repeated refinement and our tools need to support this approach. In short, our development processes are broken, and we need to apply deliberate effort to rethink our approach to systems development. The systems development life cycle (SDLC), also referred to as the application development life-cycle, is a term used in systems engineering, information systems and software engineering to describe a process for

1. planning,
2. creating,
3. testing, and
4. deploying

an information system.

• Module Objectives
  In this module you will learn to:
  1. Apply encapsulation throughout your models and your process
  2. Apply cohesion and coupling throughout your models and your process
  3. Focus on responsibility to improve cohesion and coupling
  4. Understand the purpose and process of refactoring
  5. Apply some guidelines for assigning attributes and operations

The systems development life-cycle concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. A systems development life cycle is composed of a number of clearly defined and distinct work phases which are used by systems engineers and systems developers to plan for, design, build, test, and deliver information systems. Like anything that is manufactured on an assembly line, an SDLC aims to produce high quality systems that meet or exceed customer expectations, based on customer requirements, by delivering systems which move through each clearly defined phase, within scheduled time-frames and cost estimates. Computer systems are complex and often (especially with the recent rise of service-oriented architecture) link multiple traditional systems potentially supplied by different software vendors. To manage this level of complexity, a number of SDLC models or methodologies have been created, such as

1. "waterfall";
2. "spiral";
3. "Agile software development";
4. "rapid prototyping";
5. "incremental"; and
6. "synchronize and stabilize".

In recent years, object-oriented development concepts and methods have received a lot of attention. Some outstanding success stories sing the praises of objects. The claims run as high as 90% savings in time and money, 70% to 90% savings on code.
The counterpoint to these claims is an industry-wide savings of only 10% to 30%. Some development teams even slow down because the learning curve is so steep for the new technologies and techniques. Research into why these powerful new concepts are not yielding the expected results has identified three very important causes:

1. People using the new technologies are still approaching analysis and design from a procedural and/or data-centric perspective.
2. The systems development process is not closely linked to a business reengineering process.
3. Reuse is not a priority.

This module focuses on the attitudes and practices that will help you avoid common pitfalls in software design.

The first section examines the inherent complexity of software and the ways in which complexity manifests itself. We present the object model as a means of helping us manage this complexity. In detail, we examine the fundamental elements of the object model:

1. abstraction,
2. encapsulation,
3. modularity,
4. hierarchy,
5. typing,
6. concurrency, and
7. persistence.

We address basic questions such as "What is a class?" and "What is an object?" Because the identification of meaningful classes and objects is the key task in object-oriented development, we spend considerable time studying the nature of classification. In particular, we examine approaches to classification in other disciplines, such as biology, linguistics, and psychology, then apply these lessons to the problem of discovering classes and objects in software systems.