Software Categories and Evolution

Software Categories

• System Software: A collection of programs designed to serve other programs; examples include compilers, editors, file management systems, operating systems, drivers, and network software.
• Application Software: Stands alone and solves specific business needs.
• Scientific Software: A collection of programs for scientific applications.
• Embedded Software: Resides within a product and provides features and functions for the end user; examples include keyboard control for ovens and digital functions in automobiles like fuel control.
• Product Line Software: Designed to provide specific capabilities for customers.
• Web Applications: Linked hypertext files.
• Artificial Intelligence Software: Employs non-numerical algorithms to solve problems like expert systems and playing games.

Software Evolution

• Software constantly evolves regardless of its application domain size or complexity.
• Common reasons for software evolution include error correction, adaptation to new environments, and incorporating customer-requested features and functions.
• Manny Lehman developed a unified theory for software evolution:
  • The Law of Continuing Change (1974): E-Type systems require continuous adaptation to maintain their effectiveness.
  • The Law of Increasing Complexity (1974): As an E-Type system evolves, its complexity increases, making maintenance more difficult.
  • The Law of Self-Regulation (1974): The evolution process of E-Type systems is self-regulating, with product and process measures tending towards a normal distribution.
  • The Law of Continuing Growth (1980): E-Type systems need continuous functional expansion to satisfy user expectations over their lifespan.
  • The Law of Declining Quality (1996): E-Type system quality declines unless they are maintained and adapted to environmental changes.
  • The Feedback System Law (1996): E-Type evolution involves multi-level feedback systems and must be treated as such to achieve significant improvements.

Software Characteristics

• Software is a logical system, not a physical one.
• Software is developed or engineered, not manufactured in the traditional sense.
• Software does not wear out in the same way hardware does.
• Most software is custom-built, although component-based assembly is becoming more prevalent.

Software Myths

• Software development is often surrounded by misconceptions.
  • Management Myths: Standard procedures and documentation can provide everything needed to build software.
  • Customer Myths: General objectives are enough to start programming, with details filled in later. Requirements change constantly, but software's flexibility allows for easy adaptation.
  • Practitioner Myths: Once a program is working, the developers' job is done. The only deliverable for a successful project is a working program.

Legacy Software

• Legacy software refers to older programs that have been continuously modified to meet changing business needs and computing platforms.
• They remain crucial in supporting business functions.
• Legacy software can have negative qualities including:
  • Inflexible design
  • Poor or lacking documentation
  • Complex code
  • Untracked test cases and results
  • Poorly managed change history

The Classical Life Cycle

• A systematic, sequential approach to software development.
• Begins with defining customer requirements and progresses through planning, modeling, construction, deployment, and ongoing support.

Computer-Based System

• A unified set or arrangement of components designed to achieve a specific goal through information processing.
• The goal might be to support business functions or develop a product for revenue generation.
• Key Elements of a Computer-Based System:
  • Software: Computer programs, data structures, and related artifacts that define the system's logical methods and procedures.
  • Hardware: Electronic devices providing computational capabilities and interconnectivity (networks, switches, telecommunications devices enabling data flow, electromechanical devices).
  • People: Users and operators of the hardware and software.
  • Database: A large, organized information collection accessed through software.
  • Documentation: Descriptive information explaining the system's use and operation.
  • Procedures: Steps defining how each system component is used.

The System Engineering Hierarchy

• Focuses on understanding the context and gradually narrowing the scope to define technical details.
• Begins with a "world view" of the business or product domain.
• Refines the view to focus on specific domains of interest.
• Identifies necessary system elements (data, software, hardware, people) within a specific domain.
• Initiates analysis, design, and construction of targeted system elements.

Product Engineering

• Focuses on translating customer needs into a working product.
• Drives architecture and infrastructure.
• Architecture comprises distinct system components (software, hardware, databases, people).
• Support infrastructure includes technologies to bind components together and documentation for support.

Business Process Engineering

• Involves analyzing and redesigning workflows within and between enterprises to optimize processes and automate non-value-added tasks.
• Introduced by Michael Hammer in 1990.
• Three key architectures to be considered:
  • Data architecture: Provides a framework for a business's information needs.
    • Data objects represent business elements with specific attributes.
    • Relationships between data objects define how they are connected.
  • Application architecture: Defines elements that transform data objects within the data architecture for specific business purposes.
  • Technology infrastructure: Provides support for data and application architectures.
    • Includes hardware and software like computers, operating systems, networks, storage, and telecommunications technologies.

System Modeling

• A crucial aspect of system engineering.
• Involves creating models that define processes representing the system's behavior.
• Models capture assumptions governing the behavior and relationships within the system.
• Engineers consider various factors when constructing models:
  • Assumptions: Simplify the system by reducing possible permutations.
  • Simplifications: Make model creation efficient.
  • Limitations: Define the system's boundaries.
  • Constraints: Guide the modeling process and implementation.
  • Preferences: Indicate preferred architecture for data, functions, and technology.

Data Modeling

• Addresses questions related to any data-processing application:
  • What are the primary objects processed by the system?
  • What are the components and attributes of each data object?
  • Where are these objects currently located?
  • What are the relationships between each object and others?