What is Software Engineering?

What is Software Engineering?

• Software engineering combines software and engineering principles.
• Software is a collection of integrated programs.
• It consists of organized instructions and code written in various computer languages.
• Related documentation, like requirements, design models, and user manuals, are important components.
• Engineering applies scientific knowledge to invent, design, build, and improve frameworks and processes.
• Software engineering is an engineering branch focused on evolving software products using scientific methods.
• The goal is to create effective and reliable software.

Importance of Requirement Gathering

• It ensures that all stakeholders share a common understanding of project objectives.
• Developers can understand the needs of end-users and clients, creating a product that meets expectations.
• Defining the project scope is crucial to manage expectations and prevent scope creep, keeping the project on track.
• Clear communication reduces misunderstandings among stakeholders, ensuring alignment.
• Identifying potential issues early helps minimize costly errors and delays.

Principles of Software Development

• Divide and Conquer: Break down complex problems into smaller, manageable modules for easier development, debugging, and testing.
  • An example is developing a shopping website as separate modules for inventory, payment, and user accounts.
• KISS (Keep It Simple, Stupid): Avoid unnecessary complexity in design and implementation to improve maintenance and usability.
  • Clean layouts and minimal buttons are preferable to overloading an interface.
• Simplicity Isn't Easy: Creating simple designs requires deep understanding and effort to balance functionality and simplicity.
  • Example: Google’s minimalistic design with powerful algorithms.
• Learn from Mistakes: Use failures as learning opportunities to refine practices and prevent future issues.
  • Implement rigorous testing in subsequent projects if a previous one failed due to inadequate testing.
• Remember the Reason Software Exists: Focus on solving problems and addressing user needs effectively.
  • An example is making customer feedback-driven improvements in a food delivery app.
• You Won’t Be Using the Software: Consider the end-user during design, focusing on usability, accessibility, and real-world operating conditions.
  • The use of intuitive dashboards in a medical app for non-technical healthcare professionals.

Characteristics of Software

• Functionality: The software performs specific tasks as intended; an example is an accounting app calculating taxes accurately.
• Reliability: Software shows consistent performance under defined conditions, like banking software ensuring data integrity.
• Usability: The software is easy to learn and use, even for non-technical users, such as a simple interface in a food delivery app.
• Efficiency: Optimized for minimal resource usage while maintaining performance; for example, a lightweight app running smoothly on low-end devices.
• Maintainability: It's easy to update and fix without extensive rework, exemplified by modular code design for quick bug fixes.
• Scalability: The software handles increased workload or data without performance degradation, such as e-commerce platforms managing spikes during sales.
• Portability: It runs across various platforms with minimal changes, demonstrated by games working on Windows, macOS, and Linux.

Software Myths (Management Perspectives)

• Myth 1: Having good standards and clear procedures eliminates the need to worry about software quality.
  • Quality depends on how well standards and procedures are followed, not just their existence. - A company might adopt ISO 9001 standards but still produce buggy software.
• Myth 2: Using the latest computers and state-of-the-art tools ensures product quality.
  • Skilled teams and proper processes are crucial, tools and technology alone cannot secure quality. - A team might use the latest IDE (e.g., IntelliJ IDEA) but still produce poor software.
• Myth 3: Adding more specialists with higher skills and experience can recover a delayed schedule.
  • Adding manpower to a late project can make it later due to onboarding time slowing progress. - Adding developers to a late project can cause communication overhead and task allocation conflicts.
• Myth 4: Software is easy to change.
  • Changes to a poorly designed system can introduce new bugs and complexities. - Adding a feature to a legacy banking system can disrupt existing functionality.
• Myth 5: A general statement of objectives is sufficient to start software development.
  • Ambiguity in objectives leads to rework and unmet expectations. - Lacking detailed requirements, an e-commerce app may lack secure payment option.
• Myth 6: Missing requirements can be easily incorporated as they become clear.
  • Incorporating missing requirements late in development increases cost and risk.
    • Multi-language support added near completion needing database and UI rework as an example.
• Myth 7: Software with more features is better software.
  • Feature-rich software can become bloated and less user-friendly. - A word processor with too many features may overwhelm users.
• Myth 8: Software can work right the first time.
  • Bugs and unforeseen issues are inevitable in complex systems and iterative testing is essential. - A new mobile app version requires patches after release to fix bugs.
• Myth 9: Once the software is demonstrated, the job is done.
  • Demonstration is only a milestone, deployment, training, and maintenance are critical phases. - After demonstrating a CRM system, user onboarding and troubleshooting becomes key.
• Myth 10: Software quality cannot be assessed before testing.
  • Quality can be assessed early through design reviews, code analysis, and adherence to standards. - Static code analysis tools such as SonarQube can detect potential issues before runtime testing.
• Myth 11: The only deliverable for a software project is tested code.
  • Documentation, training materials, and user guides are equally important deliverables. - Hospital management systems require detailed manuals for staff to operate effectively.
• Myth 12: The aim is to develop working programs.
  • The aim should be to deliver value by meeting user needs and ensuring long-term maintainability. - A data analytics platform lacking scalability may fail to meet future demands.

Importance of Software Engineering

• It breaks down complex projects into manageable parts, allowing for independent problem-solving.
• Software engineering helps optimize resources, reducing overall development costs.
• Well-structured development following a structured plan through software engineering reduces delays.
• Systematic planning helps in smooth progress and completion through testing and maintenance in large projects.
• Thorough testing ensures software reliability and functionality throughout its lifecycle.
• Adherence to standards makes software more efficient and effective, by following software engineering principles.

Software Product Types

• Generic Software Products:
  • These are off-the-shelf software for a broad audience, such as Microsoft Office, Adobe Photoshop, and Google Chrome.
  • Advantages include being cost-effective, widely available, tested, standardized, and feature-rich.
• Bespoke Software Products:
  • Custom software is built to meet specific needs, such as a tailored banking system or ERP for a factory.
  • Advantages include precisely meeting requirements, scalability for specific tasks, and offering competitive customization.

Comparison of Generic and Customized Products

• Generic products target broad, anonymous customers, while customized products target specific entities.
• Generic products benefit from lower costs via shared expenses, whereas custom projects have higher costs due to tailoring.
• Generic products offer standardized features, but custom solutions supply tailored functionalities.
• Examples of generic products include Microsoft Office and Linux OS; examples of custom products include specific banking software.

Difficulties in Improving Software Processes

• Tight deadlines prioritize delivery over process improvement, limiting resource allocation.
• Teams lacking expertise limit progress; for example, with Agile or DevOps methods.
• Short-term gains are favored over long-term process benefits, which causes resistance to change.
• Management may not commit resources, and teams resist adopting new processes perceiving them as unnecessary.

Terminologies

• Deliverables are generated during development, such as source code, user manuals, and operating procedure manuals.
• Milestones mark the status of the project, like specification finalization and design document completion.
• Milestones are key for project planning and management.

Product

• It is what's delivered to the customer, including source code, specification documents, user manuals, and operating procedures.
  • For instance, a customer gets an inventory system with code and documentation.

Process

• The set of activities and practices that produce the product, such as requirement analysis, design, coding, and testing.
  • Agile development to produce an e-commerce application.
• Over-reliance on processes can lead to inefficiencies, thus requiring a balanced approach as a key insight.

Measurements

• It's quantifying an attribute or characteristic like counting lines of code (LOC).

Measure

• Providing a quantitative representation of an attribute -- for example, the execution time of an algorithm is measured in Code size in Lines of Code (LOC).

Metric

• A derived measurement used for evaluation or decision-making.
  • An example is Defect Density = Total Defects / LOC.

Process Metrics

• Evaluate the development process and its environment
  • Examples are Productivity which is measured in LOC/Person Month and Efficiency which is measured in time to complete a task.

Product Metrics

• Evaluate the quality of the software product.
  • Examples are Size, which is measured in LOC or Function Points, Reliability, which is measured by the frequency of failures, as well as complexity, which is measured with Cyclomatic complexity.

Productivity

• The rate at which the product is made relative to the effort expended: Productivity = LOC/Person Month (PM).
  • A developer writing 2,000 LOC in one month has a Productivity of 2,000 LOC/PM.

Effort

• Total labor input, often measured in Person Months (PM), where a team member works for one month.

Module

• A logical unit or function in a program; examples include subroutines (Fortran), classes/packages (Java), or functions/modules (Python).

Component

• A modular, deployable, and replaceable system part that encapsulates implementation and exposes functionality via interfaces.
  • Examples are payment gateway module (e-commerce) or REST API (user authentication).

Role of Management in Software Development

• Management ensures project success, affecting product quality, process efficiency, and stakeholder satisfaction.
• Management's key aspects involve managing people, product, process, and project.

People

• Team Building: Compose the team of skilled individuals with complementary skills.
• Motivation and Leadership: Project managers should inspire the team to achieve goals, maintaining morale and handling challenges.
• Training and Development: Encourage team-member growth and updating of best practices.
• Collaboration and Communication: Facilitate smooth communication and collaboration between departments.

Product

• Defining the Product Vision: Align the product with business goals/needs regarding project features, scope, and market fit.
• Prioritization and Trade-offs: Manage time, cost, and product, and make feature-inclusion decisions.
• Quality Assurance: Ensure quality through testing, code reviews, and feedback loops.

Process

• Management decides upon software methodologies -- for instance, choosing Agile, Waterfall, or Scrum.
• Continuous Improvement: Optimize workflows, remove bottlenecks, and use feedback loops.
• Risk Management: Identify and mitigate potential risks (technical, resource-based, or timelines).

Project

• Project Planning and Scheduling: Project Management must define timelines, deadlines, and milestones to keep the project on track.
• Resource Allocation: Manage resources effectively to avoid overextending the team.
• Monitoring and Reporting: Constantly track progress, adjusting plans, and providing updates.
• Handling Budget and Cost Management: Ensure project delivery within budget, balancing scope and quality.

Dependencies and Order

• People are fundamental because developers are key.
• Defining the product ensures a clear goal of what to develop.
• The well-defined process impacts project efficiency, quality, and productivity.
• Handling project resources, timelines, and risks facilitates people-, product-, and process-alignment.

Software Development Life Cycle (SDLC)

• A structured framework defining the stages a software product goes through from inception to retirement.
• It specifies activities and ensures a systematic approach, by defining the methods, dependencies, and transition criteria, enabling project management and software development.
• Developing well means following a structured approach that ensures team members work in a co-ordinated way.
• Without proper lifecycle, lack of co-ordination can causes, inconsistencies, delays, and project failure.

Roles

• Enforcing clear phase-entry and phase-exit criteria.
• Tracking project progress through the project manager.
• Structuring/organizing workflows that reduces member confusion.
• To monitor progress and promote a discipline which reduces the need to mitigate any project delays.

SDLC Cycle Stages

• Has the key phases of planning, analysis, design, implementation, testing, deployment, and maintenance.

Requirement analysis

• It involves understanding what the client wants, identifying any risks, setting foundation and planning.

Key SDLC Activities

• Gather requirements by meeting with senior team members, analysts, organizers, and any clients.
• The project aims, the identity of any users, determination of required functional abilities, should all be considered.
• Potential risks and feasibility undergo analysis before advancing with any decision.
• Any ambiguities are further discussed with any identified stakeholders in an effort to clarify.
• Documentation of the requirements occurs with a Software Requirement Specification (SRS) prepared.
• The SRS serves as blueprint for developers, after review is performed with approval from the client.

Defining SDLC Requirements

• Once analysis has occurred, there is a formal documentation process that is completed.
• The documentation is provided in a Software Requirements Specification (SRS).
• That document should contain all functional and non-functional requirements from that product.
• It serves as an approved reference, and thus begins the development process.

Software Design

• Transforms project requirements with a structured blueprint for development.
• Includes everything from architecture, database, user experience, to technology selection of the system.
• The design is structured to be clear, scalable, and efficient, supporting future stages.

Coding and Implementation

• Begins the process on any actual code development, by implementing guidelines.
• Tools are used with languages that help developers implements the code.
• It must adhere to code maintenance, and to best practices when creating code.

Testing

• Software functionality is tested to ensure code works with the original plan.
• Testing occurs, using these common SDLC testing methods:
  • Component testing, testing each single process.
  • Module testing, checking interactions between process components.
  • System testing, validating project design, with all its functionalities.
  • Acceptance testing, ensuring requirements from stakeholders are met on project deliveries.

Deployment

• Once testing can confirm stable release and the software is effective, deployment begins.
• This release can occur using enhancement updates based on feedback..
• It occurs incrementally, with Beta testing during its phases, finishing with a full release.

Maintenance

• After real world results come out, new insights about bugs, software issues, or new ideas, will occur.
• The process of maintenance involves.
  • Bug fixes and important security updates.
  • New levels of optimization and performance of the processes.
  • Adding new functional feature options.

SDLC Software Requirements

• Two broad categories include the division largely categorized by different software needs.

Functional Requirements

• Defines a function that the system makes, by documenting across any of its systems.
• It's behavior should correlates with that and the systems functionality.

Non-Functional Requirements

• Those specifications, that determine action instead of behavior.

Sub-Categories of Non-Functional Requirements

• Run time factors like secure performance, usability with proper functionality.
• Static, structural, and scalable qualities like being evolutionary, maintaining system integrity, testing protocols and more.

Build and Fix Model in Software Development

• An easily adapted framework, used frequently when requirements change.

Model Concepts

• Creates basic simple product version for use.
• Initial iteration is used for gathering information for fixes.
• After any initial bugs or issues are fixed, its updated, by incorporating feature additions or user feedback.

Process

• An easy method for fixing any bugs.
• The fix will incorporate the testing method.

Phases

• A continuous update version.
• Continues even after any testing process is finished.
• An always proactive but reactive software type.

Model Advantages

• Is simplistic as the model is easy to use and understand.
• Testing frequently provides feedback.
• Flexibility, providing greater adaptation to the required coding.

Model Disadvantages

• Can lack planning, with a structured coding phase missing.
• Software can scale out of hand due to hard to maintain or create for the coding type.
• Creates lots of technical debt due to the focus on quick fixes.
• Inefficient due to constant iteration, where there are poorly tested systems.

Waterfall Model

• Every step is conducted with no overlap.
• Has sequential order with every project section planned that way.

Main Steps

• First, the product, its purpose and features need all requirements gathered for future use.
• Then those plans undergo rigorous review to spot omissions.
• Requirements and specifications need analysis in the SRS document.
• The goal of analysis is spotting and removing any irregularities or missing data from that project.
• Includes design process, involving the transition of SRS into usable code.

Other

• Code sources write the SRS for the specifications needed to achieve it.
• Different teams testing each code section.
• Testing alpha, with smaller development teams creating the testing with the system.
• Testing Beta, with larger outside customer-testing that is tested before general release.
• Testing Acceptance, before software testing acceptance.
• Deployment which is released with all code working to all targeted platform.
• Maintenance updates for performance, added features, and security.

When to SDLC and Waterfall

• When tools and methods are uniform, not needing change.
• For low risk manageable projects.
• To manage limited resources and be stringently strict on regulatory requirements.

Waterfall Advantages

• Easy implementation is done with minimum required resources for testing.
• Planning points remain set creating steady development flow, from start to finish.
• Fixed costs with no large requirements.
• Provides accountability to clients.

Waterfall Disadvantages

• A "no path" software where after the final product, corrections are difficult to implement and fix without major code development.
• Difficult to alter requirements due to project development.
• Cannot overlap project design to make progress as stages happen one at a time.

Waterfall Model

• Lacks clear stakeholders.
• Lack full defect protection or security.
• Offers a lengthy code cycle.

RAD (Rapid Application Development) Model

• Quick production methods by increasing component reuse and flexibility.

RAD Key Points

• Prioritization over project, for better iterations.
• Allows better prototyping because users are able to evaluate its versions.
• Dividing into small segments.
• Less paperwork required due to focus on real collaboration.

RAD Steps

• Planning requirements through FAST systems.
• Create user experience testing, with feedback and prototyping.
• Improve and expand with different automated tools.
• Interfaces will need better testing.

Why RAD?

• Suits rapid developments as long as requirements are understood.
• Suited to those project that encourage creativity.
• Great for improving existing prototypes.
• For straightforward tech that is tested fast!

RAD Advantages

• Flexible and adaptable project that sees customer priority given over all others.

RAD Disadvantages

• Requires elite teams, for better design management
• Unsuited for lower projects because it needs high costs for its automated tools.
• Requires user interaction.
• Can suffer complications due to lack of reusable elements.
• There are some systems which cannot be improved upon.

Spiral Model

• A hybrid blend of prototyping and development. Each cycle of every project is part Objective setting or Risk assessment

Main Points

• Develop various strategies during design and the processes for testing.
• Make sure to analyze and measure projects, by reviewing project processes for all project steps

When to Spiral

• Used when updates are frequent
• Requires large budgets with unclear steps

Advantages

• Its useful for risky projects where it gives more accurate testing.

Disadvantages

• Can have high costs with the model.
• Requires specific high-level risk analysis.
• Is often too difficult for smaller projects that struggle to test its code.

Incremental Model

• Requirements divides into standalone modules.

Model Steps

• Product analysis identifies needs and testing for a complete system.
• Style and development is improved as new code is established.
• Performance testing for functions occur here.

When to Use

• Whenever there are teams with different skills and long schedules.

Model Advantages

• Faster software that has client vision on the scope.
• Handles high levels of risk and support to scope.

Model Disadvantages

• Needs better planned execution and good teams.
• Can suffer from increasing costs and re-iterative code.

Agile Model

• Fast paced methodology that offers agile frameworks specific to project type, industries and sizes.

Model Steps

• After the project is planned, it then develops its requirements with that plan.
• The project constructs its elements though construction and iteration.

Agile Quality is Achieved By:

Testing and releases the product.

• The feedback provides for more analysis.

How to Use Agile

• Create stories for projects by understanding client needs and planning the requirements.
• Teams construct from beginning to finish with stages of improvement and minimal function releases first.
• Quality control makes sure its performance keeps bugs fixed.

Agile Points

• Aims for quality that satisfies clients in a reasonable time.
• Quick deliveries that provide face time with teams.

Model Disadvantages

• The lack of proper documentation causes a difficulty to maintain with a small team for a massive project.

Differences

• Agile provides a definition for design as it is designed while software sequentially flows it as it needs.

Iterative Model

• This allows first version of software, so later versions can iterate on this.

Key SDLC Steps

• Requires team meeting with customers.
• Then that gets transformed into coding with those instructions added to the software releases.
• After releases, testing occurs using white box, black box and grey box.
• With this deployed, the review process provides any errors to help the gathering process of iteration.

When to Use

• When the user has constant feedback, after clearly defined parameters.

Model Advantages

• Risk is easy to resolve from development, and change.

Model Disadvantages

• Requirements are altered and may require a lot of recoding to iterate.

Prototype

• Early model to have users refine and understand early on and increase developer vision.

Steps

• Collect the plan from the stakeholders with the system.
• Testing and development of alpha for strengths and weaknesses.
• If issues occur, refinements are made.

To Maintain

• Prevent failing, and make sure customer is as happy as possible with all expectations set.

Model Advantages

• Testing in the loop, as it goes increases satisfaction to expectations.
• The feedback promotes better design changes, in a faster way than traditional developments..
• With initial phases in testing, it provides the feedback to resolve them early.

Model Disadvantages

• The continuous changes increase deployment times and cause poor communication to the stakeholder.

Evolutionary Process Model

• Uses feedback though different areas.

Characteristics

• A method that repeats many times the various steps.
• Doesn’t require a new functioning product until testing.
• Implement requests, with set points.

Example

• Creating an interface for the first cycles.

Implementation of Key Feautues

• A more hands-on team effort that requires risk reduction.
• Should be a structured approach.

ISO 9000 Certification - About

• It's an attempt to create clear contracts between independent organizations.
• Standardized guidelines for maintaining consistent high quality for any tested system.

9000 Types of ISO Quality Standard

• 9001. • Design and development
• 9002. • Steel and car production
• 9003 - Testing implementation

How to Register

• Requires a visit to the IO registrar office. Requires applications and audits to assess the organization's structure and test their processes.

Software Engineering Institute Capability Maturity (SEI CMM) - About

• Is used to refine and test code for organizations through organized testing procedures. These processes are set over evolutionary stages.

Key CMM Steps

• Process capability is measured by the evaluation for improvements and internal organization
• It helps achieve new levels of organizational ability.
• These processes are designed to slowly take the steps up to help any business.

Levels

• Low, adhoc activity organizations.
• Project management practices
• Methods properly designed, with ISO 9000 at this level