Software Engineering Essentials: Principles and Practices
Introduction to Software Engineering
Software engineering is a discipline through which we develop or create software for computer systems and other electronic devices. It is a process where user needs are analyzed, and software is designed based on these needs. Software engineering defines scientific principles, methods, and procedures. Software engineers build software and applications using design and programming languages.
To create complex software, we should use engineering techniques. To reduce complexity, we use abstraction and decomposition. Abstraction describes only the important parts of the software and leaves irrelevant details for later stages of development, simplifying the requirements. Decomposition breaks down the software into modules, where each module performs and defines an independent task.
Purpose of Software Engineering
- To manage large software projects
- For greater scalability
- To manage costs
- To manage the dynamic nature of software
- For better quality management
Characteristics of Software Engineering
- Basic understanding of programming languages: This includes syntax, data structures, algorithms, and object-oriented programming concepts. Popular languages for beginners include Python, Java, and JavaScript.
- Knowledge of software development tools: This includes version control systems (e.g., Git), code editors (e.g., Visual Studio Code), and integrated development environments (e.g., IntelliJ IDEA).
- Ability to debug code: This involves identifying and fixing errors in your code.
- Understanding of basic computer science concepts: This includes operating systems, networking, and data management.
- Problem-solving skills: Software engineers are constantly faced with new challenges and problems to solve.
Software Process Framework
A software process framework is a pre-built infrastructure that provides a foundation for developing and executing software processes. It offers a set of reusable components, tools, and functionalities that developers can leverage to build applications efficiently and consistently.
It’s like a pre-furnished house: you can move in and start living without worrying about building the walls, plumbing, or electrical wiring. Similarly, a framework provides the essential elements of a software process, allowing developers to focus on the specific functionalities and logic of their application.
Key characteristics of a software process framework:
- Provides a foundation for software development
- Enhances modularity and reusability
- Promotes standardization
Examples:
- Spring (Java)
- Django (Python)
- Express.js (Node.js)
- ASP.NET (C#)
- Laravel (PHP)
Umbrella Activity:
- Definition: Umbrella activities encompass all activities applied throughout the software development process. They are not directly involved in developing specific features but focus on managing the overall process and ensuring its success.
- Purpose: To provide project oversight, control, and ensure quality, risk management, and configuration management.
- Examples: Project tracking and control, risk management, quality assurance, configuration management, technical reviews, and audits.
Process Model
A process model is a graphical representation of a series of activities or steps that contribute to achieving a specific goal. It is a visual tool used to analyze, understand, and improve a process by outlining its flow, interactions, and dependencies.
Key characteristics of a process model:
- Visual representation: Uses symbols, shapes, and arrows to depict the flow of activities, decision points, and data flow.
- Focus on the process: Focuses on the “what” and “how” of a process, rather than the “who” or “when.”
- Standardized notation: Typically uses standard notations, such as Business Process Modeling Notation (BPMN), to ensure clarity and consistency.
- Multiple levels of detail: Can be created at different levels of detail, from high-level overviews to detailed process maps.
Types of Process Models:
- Flowcharts: Represent the sequential flow of activities and decision points.
- Swim lane diagrams: Illustrate the roles and responsibilities involved in a process.
- Process maps: Provide a visual overview of the entire process.
- Value stream maps: Focus on identifying and eliminating waste within a process.
- State transition diagrams: Show the different states a process can be in and the transitions between them.
CMMI (Capability Maturity Model Integration)
CMMI is a process improvement framework developed by the Carnegie Mellon University Software Engineering Institute (SEI) to help organizations improve their software development processes and capabilities.
CMMI aims to:
- Guide organizations in defining and implementing effective software development processes
- Improve the quality and efficiency of software development
- Reduce risks associated with software development projects
- Help organizations achieve specific business goals
CMMI is a five-level maturity model:
- Initial: The organization has no defined process for software development.
- Managed: The organization has basic processes in place but lacks consistent implementation and measurement.
- Defined: The organization has documented and standardized processes for software development.
- Quantitatively Managed: The organization collects and analyzes data to measure and improve its processes.
- Optimizing: The organization continuously seeks to improve its processes and capabilities based on data and feedback.
Software Requirement Analysis
Software requirement analysis is a crucial stage in the software development lifecycle. It involves identifying, documenting, and analyzing the needs and expectations of stakeholders to define a clear and comprehensive set of requirements for a software system.
Key objectives of software requirement analysis:
- Understand the problem: Clearly define the problem the software will address and the desired outcomes.
- Identify stakeholders: Determine all parties involved in the project and their individual needs and expectations.
- Gather requirements: Collect information about the desired features, functionalities, and performance of the software.
- Analyze and validate requirements: Ensure that the requirements are clear, consistent, complete, and achievable.
- Document requirements: Produce a formal document outlining the agreed-upon requirements for the software.
Initiating Requirement Engineering Process
Initiating the requirements engineering process is a critical phase in software development. This phase involves identifying and defining the project’s scope, identifying stakeholders, and articulating the problem. A feasibility study is conducted to assess the project’s viability, and a risk assessment helps anticipate potential challenges. A requirements team is established, elicitation techniques are selected, and a process for requirements management is defined. Communication channels are established, and a detailed requirements plan is developed.
Requirement Analysis and Modeling Techniques
Requirement analysis and modeling techniques are crucial for building successful software. These techniques help understand user needs, identify potential problems early, improve communication, and create high-quality software. Different techniques, like interviews, data flow diagrams, and object-oriented modeling, can be used depending on the project’s size and complexity.
Software Requirement Specification (SRS)
An SRS (Software Requirements Specification) is a document prepared by a business analyst or system analyst. It describes the features and behavior of the software, i.e., how it will perform. It is a detailed description of the software system to be developed, including its functional and non-functional requirements. The SRS consists of all necessary requirements for project development. A system analyst is required to gather all the details from the customer and write the SRS document. The SRS document is an agreement between the client and the developer.
Parts of an SRS document:
- Functional requirements of the system
- Non-functional requirements of the system
- Goal of Implementation
Characteristics of an SRS document:
- Complete: The SRS document must be complete, taking all requirements related to software development.
- Consistent: It should be consistent from beginning to end so that users can easily understand the requirements. Consistency is achieved when there is no conflict between requirements.
- Feasible: All requirements included in the SRS document must be feasible to implement.
- Modifiable: The SRS document must be created in such a manner that it is modifiable.
- Testable: The entire software or individual modules must be testable.
- Correct: All requirements given in the SRS document should be correct for easy implementation.
- Verifiable: All documents of the SRS must be verified.
- Unambiguous: The modules of the software must be unambiguous so one module is compatible with another.
Note: Without a proper SRS document, it is very difficult to provide maintenance.
Project Scheduling
Project scheduling is the backbone of successful project management. It’s a roadmap, guiding the project from start to finish. By defining task sequences, estimating durations, identifying critical paths, and allocating resources, project scheduling ensures efficient resource utilization, clear communication, and timely completion within budget. This leads to happier stakeholders and a smoother project journey.
Risk Management
Software development is inherently risky, with numerous potential threats. Risk management plays a crucial role in mitigating these risks, ensuring projects are completed within budget, on time, and with high quality.
Risk Identification
Risk identification is a crucial step in project management that involves proactively identifying potential threats and opportunities that could impact the project’s success. By anticipating and preparing for potential risks, project managers can mitigate their negative effects.
Risk Projection
Risk projection, also called risk estimation, is the process of predicting the potential impact of identified risks on a project. This involves estimating the likelihood of each risk occurring and the severity of its consequences. By understanding the projected impact of risks, project managers can prioritize their mitigation efforts.
Risk Refinement
In software development, risk refinement is the process of decomposing complex or ambiguous risks into smaller, more manageable, and actionable components. This helps to clarify the nature of the risk, assess its impact and likelihood more accurately, and develop more effective mitigation strategies.
RMMM Plan
An RMMM plan (Risk Mitigation, Monitoring, and Management Plan) is a documented strategy for identifying, analyzing, mitigating, monitoring, and managing risks in a project. It plays a crucial role in ensuring project success by proactively addressing potential threats and challenges.
Total Quality Management (TQM)
Total Quality Management (TQM) is a management activity that integrates all organizational functions, such as marketing, sales, finance, product development, and customer service. It mainly focuses on customer requirements, product quality, and top management commitment and support.
- Total: The involvement and input of everyone.
- Quality: Fully meeting customer requirements and expectations.
- Management: The way we manage, operate, control, and handle our organization.
Key Principles of TQM:
- Commitment from management
- Employee environment
- Continuous improvement
- Customer requirement
Effects of TQM:
Improved Quality → Increased Productivity → Lower Costs & Higher Profit → Organizational Growth
Software Quality Assurance (SQA)
Software Quality Assurance (SQA) is an umbrella activity for checking the quality of the software, whether the software we are making is of good quality or not. SQA is not checked at any particular phase; it runs alongside software development. After every development process, software quality assurance is checked. Generally, the quality of the software is verified by a third-party organization like ISO (International Organization for Standardization) to ensure that the software is a quality product and is working according to user requirements. A software quality product has several quality factors: portability, reliability, functionality, error-free operation, maintainability, and usability.
Software Reviews
Software reviews are a vital part of the software development process, playing a crucial role in ensuring the quality, functionality, and usability of software applications. They involve a systematic evaluation of different aspects of the software, including code, design, documentation, and user interface.
There are two primary types of software reviews:
- Internal Reviews: Conducted by members of the development team (developers, testers, designers, and project managers). Internal reviews can be carried out at various stages, from early code reviews to usability testing.
- External Reviews: Conducted by individuals or groups outside the development team (independent consultants, industry experts, or potential users). External reviews provide a fresh perspective and can identify issues that may be missed by the development team.
Matrix for Process and Projects
The specific matrix for process and projects in software will depend on the particular chapter and software development methodology. However, some common elements are often included:
Processes:
- Requirements analysis and modeling: Gathering and analyzing user needs and translating them into technical specifications and models.
- Design: Creating the overall architecture and detailed design of the software.
- Implementation: Writing the code, unit testing, and integrating the different software components.
- Testing: Testing the software for functionality, performance, security, and usability.
- Deployment: Releasing and installing the software in production.
- Maintenance: Fixing bugs, adding new features, and updating the software to ensure it continues to meet user needs.
Projects:
- Project name: The name of the software project.
- Project description: A brief overview of the project’s goals and objectives.
- Project scope: The boundaries of the project, defining what is included and excluded.
- Project schedule: The timeline for completing the project, including milestones and deadlines.
- Project budget: The estimated cost of completing the project.
- Project resources: The people, equipment, and materials needed to complete the project.
Design Concepts
Design concepts in software development are fundamental ideas and principles that guide the creation of effective systems. These include abstraction, modularity, encapsulation, and reusability, providing a foundation for designing robust and maintainable software.
Architectural Design Elements
Architectural design elements are high-level structures and patterns used to organize software systems. Examples include client-server architecture, microservices, and layered architectures. These elements ensure scalability, maintainability, and performance.
Software Architecture
Software architecture involves the overall structure of the software, defining components and their relationships. It serves as a blueprint, guiding developers in creating a cohesive and scalable solution.
Data Design at the Architectural Level
Data design at the architectural level involves decisions about how data is organized, stored, and accessed. This includes choosing databases, defining data models, and establishing data flow patterns.
Data Design at the Component Level
At the component level, data design focuses on detailed specifications for individual components. This includes defining data structures, formats, and algorithms used by each component.
Mapping of Data Flow into Software Architecture
Mapping data flow into software architecture involves aligning data movement with architectural patterns. This ensures coherent data processing and communication between components.
Modeling Component-Level Design
Modeling component-level design entails creating detailed representations of components. This includes specifying internal structures, interfaces, and interactions, providing a roadmap for implementation.
Coding
Coding is an essential part of software engineering for developing dynamic and reliable software. By using coding, we transform the design of a system into a programming language. We should implement well-defined standards for coding, known as coding standards. Using coding standards makes our code easily understandable, easily debugged, error-free, and extensible according to requirements. Coding standard guidelines are rules for writing code, ensuring overall code understandability.
Coding standards include:
- Limited use of global variables
- Exception handling mechanisms
- Naming conventions for global variables, local variables, and constants
- Use of comments
- A module should contain a maximum of 10-20 lines of code
- Avoid clever or difficult-to-understand code
- Do not use the same identifiers for multiple purposes
- Do not use short forms for variable and method names
Testing
Testing means software testing. It involves finding bugs in developed or existing software. Before discussing types of testing, we need to know about:
- (i) Black box testing (functional testing)
- (ii) White box testing (structural testing)
Types of Testing:
- Black box testing: The tester does not have knowledge of the coding. We only check the functionality of the software: the input passed and the output produced.
- White box testing: The tester has knowledge of the existing software and whether the internal structure is correct.
- Unit testing: Checks independent and individual units or modules of the software.
- Integration testing: Integrates all modules one by one and checks compatibility issues (whether one module is compatible with another).
- System testing: Puts the software in different environments and checks whether the software is compatible with the new environment. Overall system testing is performed by the tester.
- Stress testing: Checks how the system behaves under heavy load, i.e., the capability of the software and how much load it can handle.
- Performance testing: Checks the speed and effectiveness of the software to ensure it generates results within the specified time.
- Usability testing: Checks the GUI part created by the developer to see if it is user-friendly.
- Acceptance testing: Checks if the delivered product meets the requirements and works as expected by the customer.
- Alpha testing: The last testing done by the developer’s side just before delivery. The developer provides inputs and measures the output.
- Beta testing: The customer checks the functionality and provides feedback to the development team on whether the software provides good results.
Verification: “Are we building the product right?”
Validation: “Are we building the right product?”
Different Approaches to Software Design
- Function-Oriented Design (FOD): The top-level module is successively decomposed into sub-modules, where each module has a well-defined task.
- Object-Oriented Design (OOD): Instead of concentrating on functions, we concentrate on objects. An object contains both data and functions used to create applications. The entire system is viewed as an object. Each object has its own state and behaviors.
Why ISO Certification?
- An ISO-certified company has a big name in the international market.
- The company acquiring ISO certification changes its internal structure mechanism to implement quality services in the process, not just the final product.
- We can increase renewals and business because once ISO certified, customers start believing in the organization.
- ISO provides benchmarks and guidelines for every organization certified by ISO.
- The progress of the product can be easily measured, and reports can be provided to top-level management.
Software Maintenance
Software maintenance is a very important activity because we want better performance from our software. Software must be upgraded and maintained regularly, depending on user requirements or changes in technology. Software maintenance is needed to correct errors in the existing product, enhance features, and implement the software on new platforms. Previously, software maintenance was neglected, but currently, we focus more on software maintenance compared to software development.
Types of Software Maintenance:
- Corrective maintenance: Addresses problems reported by users while using the software product.
- Adaptive maintenance: Describes the ability to run on different platforms, different operating systems, and changes in the GUI depending on new software or hardware.
- Perfective maintenance: Ensures the software supports new features, different functions, and can be extended according to user requirements.
Data Flow Diagram (DFD)
A DFD (Data Flow Diagram), also known as a bubble chart, represents the flow of data graphically in an information system. Using a DFD, we can easily understand the overall functionality of the system because the diagram represents the incoming data flow, outgoing data flow, and stored data in a graphical form. It describes how data is processed in a system in terms of input and output. A DFD model uses notations or symbols to represent the flow of data:
- External Entity (square)
- Data Flow (arrow)
- Process or Bubble (circle)
- Data Store (equal sign =)
Rules of DFD:
- Each process should have at least one input and one output.
- Each data store should have at least one data flow in and one data flow out.
- All processes in a DFD go to either another process or a data store.
- All external entities must be connected through a process. An entity can provide something to the software as well as consume some data from the software.
Levels of DFD:
- 0th Level DFD: A diagram that provides the entire system’s data flows and processing with a single process (bubble) is called the context.
- 1st Level DFD: A more detailed version of the previous level that includes databases and various important units.
Software Reverse Engineering
Software reverse engineering, also known as back engineering, is the process of recovering and understanding the basic method, design, and requirement specifications of a legacy software product. First, we analyze the already created software’s source code and then recreate it to find the original code with some improvements. Simply put, it is a process to rethink, restructure, and rebuild our legacy software.
Software Development Life Cycle (SDLC)
SDLC (Software Development Life Cycle) model describes the sequence of phases or steps to develop any software. In simple words, it’s the entire lifetime of software from beginning to end. It contains three main stages:
- (i) Conception stage
- (ii) Implementation stage
- (iii) Maintenance stage
The SDLC model is classified into three categories based on their advantages and disadvantages:
- (i) Waterfall model
- (ii) Prototype model
- (iii) Spiral model
(i) Waterfall Model
Stages: (a) Feasibility study, (b) Requirement specification, (c) Design, (d) Coding, (e) Testing, (f) Maintenance (Review)
- The waterfall model is the simplest and most classical of all models.
- This model is also known as the linear sequential model.
- This model is theoretical, not practical.
- In this model, every phase must be completed before moving to the next phase.
- This model is suitable for small projects where technical issues are very clear.
- At the end of each phase, a review takes place.
Advantages of the Waterfall Model:
- Very simple and easy to use for small projects.
- Once a phase is successfully completed, we move to the next phase, so there is no overlapping.
- Each phase has a well-defined task and a review phase.
Disadvantages:
- Not suitable for large projects.
- Cannot move back to a previous phase.
- Contains high risk.
- Poor model for complex and object-oriented projects.
(ii) Prototype Model
- It is a very famous software development model.
- The client is involved in designing the system.
- The prototype model is modified until the client is satisfied, then we move to the next phase.
- The goal is to provide a system with overall functionality.
- It is an iterative development cycle between the developer and the client.
- The prototype model can be used with other models.
Advantages of the Prototype Model:
- If users are not satisfied with the prototype, a new prototype is created.
- Customer feedback is available for a better system.
- It takes less time to make this project because once requirement analysis is done, development is faster.
- Errors can be detected at an earlier stage.
Disadvantages:
- Total dependency on the prototype.
- Sometimes it takes a long time to develop the prototype based on user requirements.
- The developer may try to reuse the prototype in another project, even if it is not feasible.
(iii) Spiral Model
Stages: (a) Planning, Requirement Gathering, (b) Risk Analysis, Prototyping, (c) Project Evaluation, Evaluation, (d) Coding, Testing, Engineering Product
- Developed by Barry Boehm in 1986 as part of SEI (Software Engineering Institute).
- It is called a meta-model (model about models) because it contains all life cycle models.
- The main purpose is to reduce risk.
- A business analyst is required to reduce risk with the help of developers and clients to estimate the development cost.
- Suitable for large and complex projects.
- It is called a spiral because the same activities are repeated for all loops (spirals).
- Each spiral or loop represents the software development process.
Advantages of the Spiral Model:
- Risks are analyzed at the early stage of project development.
- Very famous model for developing large and complex projects.
- Best technology is used.
- Customer feedback is available regularly.
Disadvantages:
- The cost of the project will be high because a system analyst is required to analyze the risk.
- Not suitable for small projects.
- Each loop contains four quadrants, so it takes more time to complete.
COCOMO (Constructive Cost Model)
- COCOMO stands for “Constructive Cost Model.” It is a famous model used to estimate project costs.
- Proposed by Boehm in 1981.
- Using this model, we can estimate the time (months) and the number of team members needed to develop a project.
- According to Boehm, project cost estimation should be done in three stages:
- Basic COCOMO
- Intermediate COCOMO
- Complete COCOMO
(i) Basic COCOMO
The basic COCOMO model gives an approximate estimate of project parameters; it predicts the effort and cost. The following formula is used:
Effort = a1 * (KLOC)^a2 PM
Tdev = b1 * (Effort)^b2 months
(ii) Intermediate COCOMO
This is an extension of the basic COCOMO model. It uses 15 additional predictors, considering its environment to estimate a value or cost.
(iii) Complete COCOMO
The complete COCOMO model is an extension of the intermediate COCOMO model. This model is phase-sensitive. It is used to calculate the amount of effort required to complete each phase:
- Planning and requirement
- System design
- Detailed design
- Module code & test
- Integration & test
- Cost Constructive Model
Why Reverse Engineering is Required
Sometimes situations arise that require the use of reverse engineering. For example, if a company wants to manufacture a specific part of a machine but does not have the design, reverse engineering will first be used to understand the design and manufacturing process of that part. After that, the part will be manufactured.
Reverse Engineering: Requirement → Design → Module Specification → Code (Legacy)
Forward Engineering: Requirement → Design → Module → Code (Legacy)
Coupling
We represent coupling in “Top-level Design,” and it describes the inter-dependency and interaction between the modules of software. Coupling should be low for better software design.
Types of Coupling:
- (i) Content coupling
- (ii) Common coupling
- (iii) External coupling
- (iv) Control coupling
- (v) Stamp coupling
- (vi) Data coupling
(Low to High)
Cohesion
Cohesion represents detailed design and describes how the elements in a particular module are closely related to each other. It should be high for better software design.
Types of Cohesion:
- (i) Functional cohesion
- (ii) Sequential cohesion
- (iii) Communication cohesion
- (iv) Procedural cohesion
- (v) Temporal cohesion
- (vi) Logical cohesion
- (vii) Coincidental cohesion
Difference Between Cohesion and Coupling
Cohesion:
- Describes the relationship between two or more elements of a particular module.
- Focuses on the functional strength of the module.
- Should be high.
- Represents top-level design.
Diagram: [Module]
Coupling:
- Describes the relationship between two or more modules.
- Focuses on the dependency between modules.
- Should be low.
- Represents detailed design.
Diagram: [Module] — [Module]