SE (P1/ C2 - 2) - Software process

Process activities (in software processes)

Real Software processes involve technical, collaborative, and managerial activities aimed at specifying, designing, implementing, and testing a software system. These activities are often supported by various tools such as requirements management systems, design model editors, program editors, automated testing tools, and debuggers.

• The four fundamental activities of specification, development, validation, and evolution, are organized differently depending on the development process:

  • Waterfall Model: Activities are organized in sequence.

  • Incremental Development: Activities are interleaved.

• Execution Factors: The approach to carrying out these activities depends on:

  • The type of software being developed.

  • The experience and competence of the developers.

  • The type of organization developing the software.

Requirements engineering

Software specification or requirements engineering is the process of understanding and defining what services are required from the system and identifying the constraints on the system’s operation and development.

Requirements engineering is a particularly critical stage of the software process, as mistakes made at this stage inevitably lead to later problems in the system design and implementation.

NOTE: page 54 for more understanding

The framework of The Requirements Engineering Process

• The requirements engineering process (Figure 2.4) aims to produce an agreed requirements document that specifies a system satisfying stakeholder requirements.

• Requirements are usually presented at two levels of detail. End-users and customers need a high-level statement of the requirements; system developers need a more detailed system specification.

What are the three main activities in the requirements engineering process

1. Requirements elicitation and analysis involves deriving system requirements by studying existing systems, engaging with users and procurers, conducting task analysis, and possibly creating system models and prototypes to gain a clear understanding of the system to be specified.

2. Requirements specification translates the findings from requirements analysis into a document defining user requirements (abstract statements for customers and end-users) and system requirements (detailed functionality descriptions).

3. Requirements validation ensures requirements are realistic, consistent, and complete. Errors in the requirements document are identified and corrected to ensure accuracy and reliability.

Software design and implementation

• A software design is a description of the structure of the software to be implemented, the data models and structures used by the system, the interfaces between system components and, sometimes, the algorithms used.

• The implementation stage of software development is the process of developing an executable system for delivery to the customer. Sometimes this involves separate activities of software design and programming.

Designers do not arrive at a finished design immediately but develop the design in stages. They add detail as they develop their design, with constant backtracking to modify earlier designs.

NOTE: Read page (57-59) for more details

Four activities that lead to the software design outputs

• Architectural Design: Involves defining the overall structure of the system, including its principal components, their relationships, and distribution across the system.

• Database Design: Focuses on designing system data structures and their representation within a database, considering whether to reuse an existing database or create a new one.

• Interface Design: Specifies the interfaces between system components to ensure clarity and unambiguous interaction. Precise interface definitions enable components to be used without needing knowledge of their internal implementation.

• Component Selection and Design: Involves searching for reusable components; if none are suitable, designing new ones. Designs at this stage range from simple component descriptions to detailed UML models that can be used for automated implementation generation.

Software testing & validation

• Software validation or, more generally, verification and validation (V & V) is intended to show that a system both conforms to its specification and meets the expectations of the system customer. However, most V & V time and effort is spent on program testing.

• Program testing, where the system is executed using simulated test data, is the principal validation technique. Validation may also involve checking processes, such as inspections and reviews, at each stage of the software process from user requirements definition to program development.

The three stages of testing process?

• Component Testing: The components making up the system are tested by the people

  developing the system. Each component is tested independently. using automated testing tools.

• System Testing: Integrates components to validate system-wide functionality, identify interaction errors, and ensure all requirements are met.

• Customer Testing: Final stage before deployment, where the system's customer or potential users. test the system with real data to uncover issues in requirements, performance, or user satisfaction.

Beta testing

Beta testing involves delivering a system to a number of potential customers who agree to use that system. And They report problems to the system developers.

This exposes the product to real use and detects errors that may not have been anticipated by the product developers. After this feedback, the software product may be modified and released for further beta testing or general sale.

Changes in SD phase

Change in software development leads to rework, increasing costs due to repeated analysis, redesign, programming changes, and testing.

What are the two related approaches can be used to reduce the costs of rework.

1. Change anticipation involves predicting future modifications early in the software development process. For instance, prototyping allows customers to refine requirements before extensive development.

2. Change tolerance focuses on making the software adaptable to modifications. Incremental development allows changes to be incorporated in smaller increments, reducing the impact on already developed parts of the system.

Prototyping in SDP

A prototype is an early version of a software system that is used to demonstrate concepts, try out design options, and find out more about the problem and its possible solutions.

NOTE: for more understanding, read page 62-63

What can a software prototype help with?

A software prototype can be used in a software development process to help anticipate changes that may be required:

1. In the requirements engineering process, a prototype can help with the elicitation and validation of system requirements.

2. In the system design process, a prototype can be used to explore software solutions and in the development of a user interface for the system.

Objectives and Management in Prototype Development

In prototype development, clear objectives are crucial for success. These objectives could focus on user interface development, validating system requirements, or demonstrating applications to managers. Each prototype typically targets specific objectives to avoid misunderstandings and ensure stakeholders receive expected benefits.

NOTE: A process model for prototype development is shown in Figure 2.9.

Incremental delivery

Incremental delivery (Figure 2.10) is an approach to software development where some of the developed increments are delivered to the customer and deployed for use in their working environment.

NOTE: for more understanding, read page 64

What are the advantages of Incremental delivery

1. Customers can use the early increments as prototypes and gain experience that

   informs their requirements for later system increments.

2. Customers do not have to wait until the entire system is delivered before they

   can gain value from it.

3. The process maintains the benefits of incremental development in that it should

   be relatively easy to incorporate changes into the system.

4. Customers are less likely to encounter software failures in the most important parts of the system.

Process Improvement

Process improvement means understanding existing processes and changing these processes to increase product quality and/or reduce costs and development time.

Two quite different approaches to process improvement and change are used

1. The process maturity approach emphasizes adopting good technical and management practices to enhance product quality and predictability in software development.

2. Agile methods prioritize iterative development and minimizing process overheads to swiftly deliver functionality and adapt to evolving customer needs, aiming for efficient processes with minimal bureaucracy.

NOTE: for more understanding, read page 66-68

What are the levels of the Process Maturity model

1. Initial: Clearly defines project scope and goals, ensuring communication among team members about work to be performed.

2. Managed: Implements organizational policies for process usage, with documented project plans and resource management procedures across the institution.

3. Defined: Standardizes processes across the organization, tailoring them to meet project requirements from a defined set of processes. Collects process assets and measurements for future improvements.

4. Quantitatively managed: this level requires using data and statistics to actively control and improve subprocesses.

5. Optimizing: At this top level, process and product data are used to continuously improve processes and adapt to changing business needs.