Unit 1: Introduction to Software and Software Engineering

Exploring the fundamentals of software development, software characteristics, web-based applications, and software engineering layered technology, myths, and process frameworks.

Unit 1: Introduction to Software and Software Engineering

Software development is a complex and evolving field that requires a structured approach to be successful. This unit introduces the fundamental concepts of software, the discipline of software engineering, and the frameworks used to guide the development process.

1.1 Software – Definition, Characteristics

What is Software?

Software is more than just a computer program. It is a comprehensive entity comprised of three primary components:

  1. Instructions (Computer Programs): Executable code that provides desired features, functions, and performance when executed.
  2. Data Structures: Organized information that enables the programs to adequately store, manipulate, and retrieve data.
  3. Documentation: Manuals, guides, and models that describe the operation, design, and use of the programs.

Characteristics of Software

To understand software engineering, it is crucial to recognize how software differs from hardware. Hardware is a physical product, whereas software is a logical product. The distinct characteristics of software include:

  1. Software is developed or engineered, not manufactured: Unlike hardware, which undergoes physical manufacturing, software development is an intellectual process. While both activities require high-quality execution, software does not have a traditional "assembly line." Its quality is fundamentally established during the design and engineering phases.

  2. Software doesn't "wear out": Hardware exhibits a "bathtub curve" failure rate—it fails early due to manufacturing defects, works reliably for a period, and then starts failing again as parts wear out over time. Software, however, does not degrade physically. If it works perfectly today, it will theoretically work perfectly tomorrow. However, software does deteriorate. As changes and updates are made to adapt to new requirements, new bugs are introduced, leading to a degradation in quality over time if not properly maintained.

  3. Most software continues to be custom-built: While hardware relies on standard, reusable components (like standardized screws, microchips, and motherboards), software has historically been custom-built from scratch. However, modern software engineering increasingly advocates for component-based construction, where reusable blocks of code (libraries, frameworks, and APIs) are used to assemble new systems.

1.2 Characteristics of Web-based Applications

Web-based applications (WebApps) differ significantly from traditional desktop software. Because they reside on networks and cater to a vast and diverse user base, they exhibit the following unique characteristics:

  1. Network Intensiveness: WebApps rely heavily on the Internet or Intranets. They must operate across varying network speeds and infrastructures.
  2. Concurrency: A large number of users may access a WebApp simultaneously. The application must handle multiple concurrent interactions without failing.
  3. Unpredictable Load: The number of users can fluctuate wildly. A WebApp might have 100 users on a normal day but 100,000 users during a major event or marketing campaign.
  4. Performance: Users expect rapid response times. If a WebApp is too slow, users will abandon it. Performance optimization is critical.
  5. Availability: Many WebApps must be available 24/7. Downtime translates to lost revenue and damaged reputation.
  6. Data Driven: The primary function of many WebApps is to use hypermedia to present text, graphics, audio, and video content to the end user. They are deeply integrated with databases.
  7. Content Sensitive: The quality and aesthetic nature of content remain critical. If content is outdated or poorly presented, the user experience suffers.
  8. Continuous Evolution: WebApps are rarely "finished." They evolve continuously with frequent updates, new features, and content changes, sometimes on a daily basis.
  9. Immediacy: There is a compelling need to get software to the market quickly. WebApps often have much shorter development cycles than traditional software.
  10. Security: Because WebApps are accessible over networks, they are vulnerable to unauthorized access, data theft, and malicious attacks. Security must be an integral part of the design.
  11. Aesthetics: An undeniable part of the appeal of a WebApp is its look and feel. UI/UX design is as important as technical functionality.

1.3 Software Engineering – A Layered Technology

Software engineering is defined as the establishment and use of sound engineering principles to obtain economical software that is reliable and works efficiently on real machines. It is fundamentally a layered technology composed of four distinct layers:

  1. A Quality Focus (The Bedrock): Any engineering approach must rest on an organizational commitment to quality. Total quality management (TQM) and continuous process improvement foster a culture where high-quality software is the ultimate goal.
  2. Process (The Foundation): The process layer is the foundation of software engineering. It defines a framework for delivering software on time and with good quality. The process dictates the flow of activities, milestones, deliverables, and quality assurance checkpoints.
  3. Methods (The "How-To"): Software engineering methods provide the technical techniques for building software. Methods encompass a broad array of tasks, including communication, requirements analysis, design modeling, program construction, testing, and support.
  4. Tools (Automated Support): Software engineering tools provide automated or semi-automated support for the process and the methods. When tools are integrated so that information created by one tool can be used by another, a system for the support of software development, called Computer-Aided Software Engineering (CASE), is established.

1.4 Software Myths

Over the years, numerous misconceptions and false beliefs about software development have emerged. These "myths" are propagated by management, customers, and developers alike.

1. Management Myths

  • Myth: "We already have a book full of standards and procedures for building software. That will provide my people with everything they need to know."
    • Reality: Standards may exist, but are they used? Are they modern and adaptable? Often, manuals gather dust and do not reflect the current realities of agile development.
  • Myth: "If we get behind schedule, we can just add more programmers and catch up."
    • Reality: Software development is not a highly partitionable task like manufacturing. Adding people to a late project often makes it later. This is known as Brooks's Law. New members require training and communication overhead, slowing down the existing team.
  • Myth: "If I decide to outsource the software project to a third party, I can just relax and let that firm build it."
    • Reality: If an organization does not understand how to manage and control software projects internally, it will invariably struggle when managing outsourced projects.

2. Customer Myths

  • Myth: "A general statement of objectives is sufficient to begin writing programs; we can fill in the details later."
    • Reality: Ambiguous initial requirements are the primary cause of software failure. Formal and detailed requirements are necessary before heavy coding begins.
  • Myth: "Software is flexible, so project requirements continually change, and change can be easily accommodated."
    • Reality: While software is soft, changing requirements later in the development cycle is significantly more expensive and disruptive than changing them early on.

3. Practitioner's Myths

  • Myth: "Once we write the program and get it to work, our job is done."
    • Reality: Industry data indicates that 60% to 80% of all effort expended on software occurs after it is delivered to the customer for the first time (maintenance phase).
  • Myth: "Until I get the program running, I have no way of assessing its quality."
    • Reality: Quality assurance mechanisms, such as technical reviews and design walk-throughs, can and should be applied from the very beginning of the project.
  • Myth: "Software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down."
    • Reality: Software engineering is not about producing documents; it is about creating a quality product. Better quality reduces rework and ultimately speeds up delivery.

1.5 Software Process Framework and Umbrella Activities

A software process is a collection of activities, actions, and tasks that are performed when some work product is to be created.

The Process Framework

A process framework establishes the foundation for a complete software engineering process by identifying a small number of framework activities that are applicable to all software projects, regardless of their size or complexity. A common process framework includes the following five activities:

  1. Communication: Involves heavy interaction with customers and stakeholders to gather requirements and define the system's goals.
  2. Planning: Establishes a "map" for the team. It defines the project schedule, risks, resources, and tasks to be completed.
  3. Modeling: Creating models (sketches, diagrams) to help the developer and the customer better understand software requirements and the design that will achieve those requirements.
  4. Construction: This activity combines code generation (manual or automated) and the testing required to uncover errors in the code.
  5. Deployment: The software (as a complete entity or as a partially completed increment) is delivered to the customer who evaluates it and provides feedback based on the evaluation.

Umbrella Activities

While the framework activities operate sequentially or iteratively, Umbrella Activities occur throughout the entire software process. They are applied across all framework activities and help the team manage, track, and ensure quality. Typical umbrella activities include:

  • Software Project Tracking and Control: Allows the team to assess progress against the project plan and take corrective action to maintain the schedule.
  • Risk Management: Assesses risks that may affect the outcome of the project or the quality of the product.
  • Software Quality Assurance (SQA): Defines and conducts the activities required to ensure software quality throughout the project lifecycle.
  • Technical Reviews: Evaluates software engineering work products in an effort to uncover and remove errors before they propagate to the next activity.
  • Measurement: Defines and collects process, project, and product measures that assist the team in delivering software that meets customers' needs.
  • Software Configuration Management (SCM): Manages the effects of change throughout the software process. It keeps track of versions and modifications.
  • Reusability Management: Defines criteria for work product reuse and establishes mechanisms to achieve reusable components.
  • Work Product Preparation and Production: Encompasses the activities required to create work products such as models, documents, logs, forms, and lists.