Understanding Software: Types, Development, and Engineering Principles

Posted on Jan 5, 2025 in Other subjects

What is Software?

A software is a set of programs, documentation, and operational procedures. They are arranged in a set of instructions so that they can be understood and executed by a computer.

Features of Software

• It does not wear out.
• It deteriorates.
• Complex maintenance.
• It is made to order.
• Component reuse.

Software Categories

Basic Software

Characterized by strong interaction with computer hardware.

Examples: operating systems, drivers, compilers, etc.

Real-Time Software

Functions: monitoring, analysis, and control of events.

Examples: digital air traffic control, watches, etc.

Commercial Software

Operations that facilitate commercial decisions and administrative tasks.

Examples: payroll, inventory control, etc.

Scientific and Engineering Software

Characterized by the processing of numerical data.

Requires great hardware robustness.

Examples: astronomy, volcanology, CAD tools, etc.

Embedded Software

Control of products and industrial systems for consumer markets.

Examples: keyboard control for microwave ovens, digital functions of automobiles, etc.

Personal Computer Software

Involves many different types of software used for different purposes.

Examples: text processors, electronic spreadsheets, games, data management, etc.

Artificial Intelligence Software

Difficult problems computationally modeled by non-traditional models.

Examples: knowledge-based systems, expert systems, neural networks, genetic algorithms, games, theorem proving, robotics, machine learning, etc.

Web Software

Systems to be used through an internet browser.

Examples: personal pages, portals, data-based consulting, etc.

Software Crisis

Problems encountered in software development:

• They do not work.
• High software maintenance.
• Meeting a growing demand.

Problems with Software

• Customer dissatisfaction is frequent.
• Software maintenance is difficult.
• The quality of the software product is not guaranteed.

Causes of the Problems

• Technology advances faster than humanity itself.
• Software does not evolve at the speed at which new requirements are prescribed.
• Development is still a craft.
• Resistance to change by professionals.

Software Engineering Challenges

• Satisfy project participants: users, executives, and developers.
• Process with no guarantee of quality.
• Estimate time and costs.
• Guarantee product quality.
• Maintainability (ease of modification).
• Usability (ease of understanding).
• Efficiency (response time).
• Portability (ease of adaptation).
• Reliability (fault tolerance).
• Functionality (adequacy to the problem).

Relevant Factors

• Progress of information technologies.
• Increased level of demand from users.
• Increased demand for competitiveness and new services.

Myths of Software

• “We already have a manual that will provide everything to my staff, or they will know more precisely.”
• “Programmers can add more, and pulling more will delay…”
• “The more details you can fill in, the better.”
• “Changes can be easily accommodated because software is flexible.”
• “Once we write the program and get it working, our work is done.”

Software Engineering

The establishment and use of sound engineering principles to economically obtain software that is reliable and operates efficiently on real machines.

A discipline of computer science that offers methods and techniques to develop and maintain high-quality software tools for problem-solving.

• Methods – how to build software.
• Tools – automated support for methods.
• Procedures – the sequence in which the method is applied.

Methods, Tools, and Procedures

• Allow the manager to control the software development process.
• Provide a basis for building high-quality software.
• Meet customer requirements and expectations.

Methods

Define different types of tasks to be performed.

Establish criteria for measuring software quality and requirements.

Tools

Can support software development at different levels.

Support environments for software development.

Example: an environment that generates code based on modeling, etc.

Procedures

Indicate how to execute, in practice, the tasks defined by the methods.

Software Engineering

The fundamental objective of any engineer: to deliver the project as economically as possible, minimizing time and effort.

Paradigms

These activities can be grouped into different stages. The rules that define these stages, milestones, and sequences are called software engineering paradigms.

Types of Paradigms

• Classic stages (waterfall).
• Prototyping model.
• Spiral model.
• Incremental model.
• RAD model (Rapid Application Development).
• XP model (eXtreme Programming).
• Component assembly model.
• Formal methods model.
• Combination of paradigms.

Choosing a Paradigm

Consider:

• Customer expectations.
• Type of application to be developed.
• Methods and tools to be used.

Life Cycle

The definition of the steps to transform an idea into the finished product.

Parts of the Life Cycle

• Phases: Indicate the progress of the project steps.
• Activities: Actions required to carry out and deliver the project.
• Subproducts: Tangible products generated during the project.
• Milestones (DM): Major events in the project (decision times).

Life Cycle Objectives

• Definition of control points.
• Monitoring and planning of progress and budget.
• Risk estimation and management.

Classic Life Cycle

Modeled on the waterfall or waterfall model.

It was developed based on the civil engineering cycle.

It is characterized by a sequential approach.

Each activity is a different phase.

Phase 1 – Systems Engineering

• Achieve objectives.
• High-level analysis – little design.
• Global view of the system: tasks, user interface, hardware interface, integration with other systems.
• Available resources – HW, SW, PW, financial, time, working conditions.

Phase 2 – Requirements Analysis

• Identify user needs.
• Analyze the necessary resources, both personnel and tools.
• Perform an initial design of the global system, including its division into modules.

Phase 3 – Design

• Refine the global system specification generated in the analysis phase.
• The objective is a more detailed specification of the system.

Phase 4 – Coding

Consists of simply implementing the project that was defined.

Phase 5 – Testing

• There is no system without bugs.
• V model, W model, and other models.
• Fixing a defect when the system is being developed is much cheaper.

Phase 6 – Maintenance

Most likely, changes will occur after the software is delivered to the customer.

Due to new functionality required or errors.

Types of Maintenance

• Corrective, evolutionary, and adaptive maintenance.

Problems with the Waterfall Model

• Real projects do not follow a sequential flow.
• It is not always possible to establish, initially, all the necessary requirements.
• The customer must wait until the end of all stages to find out what the product will be like.

Waterfall Model – Summary

Use Cases

Objectives

They must answer:

• Who are the actors involved?
• What are their goals?
• What preconditions exist?
• What are the main tasks performed?
• What exceptions should be considered?

Steps

• Identification of the actors involved.
• Capture of use cases.
• Creation of the diagram.
• Elaboration of the description of each use case.
• Analysis of possible associations between use cases.

Identification of Actors

An actor is a specific role played by a user.

It defines anything external that can interact with the system: users, other systems, devices, etc.

How to Identify Actors?

• Who uses the system?
• Who maintains the system?
• What other systems are used by it?
• Who gets information from the system?
• Who provides information to the system?

How to Identify Use Cases?

• What functions will the actor want to do in the system?
• Does the actor store information?
• Will they create, read, or update this information?
• Will they notify an actor about a change?
• Will external events notify the system?
• Will the system notify me about events?

Use Case Diagram

They describe a view from outside the system.

They separate external elements (actors) from internal elements (use cases).

Use Cases

They represent an activity of the system that it performs (external view).

They serve to meet an actor’s objective.

They have an additional textual description.

Actor

Represents external elements to the system.

What Should Be in the Description

• Name of the use case.
• Brief description/objectives.
• Preconditions and postconditions.
• Normal flow.
• Alternative flow.
• Actors.
• Restrictions.
• Observations (if any).

Normal and Alternative Flow

• Normal Flow: Perfect world, everything happens as planned.
• Alternative Flow: Exceptions, errors, etc.

Relationships

Association

Demonstrates that an actor uses a given function of the system represented by the use case – receiving input, producing output, or executing a requirement.

Generalization/Specialization

When an actor is strongly related to another actor, so that one is a type of the other (secondary actor and primary actor). The same process occurs in use cases.

Inclusion (include)

When several instances have a common subsequence of functioning, it is convenient to separate this common part into a new use case that is included in the first ones.

An instance of use case A includes the specified behavior of B.

It avoids writing the same sequence of steps in several use cases, focusing this sequence on a single event accessed by others.

When a use case A includes a use case B, it indicates that the behavior of use case B is reused by the behavior of use case A.

Extension (extend)

They describe scenarios that will only occur in a specific situation.

When a use case B extends a use case A, it indicates that the behavior of use case A is extended with the behavior of use case B.

It is used to show the behavior of special cases and exceptions that would increase the complexity of the use case.