A software process is the application of a systematic, disciplined and quantifiable approach to the development, operation, and maintenance of software, that is, the application of engineering to software.
Software engineering is concerned with the cost-effective and timely development of high quality software predictably, particularly for large scale systems.
Some concepts:
Specification: defining what the system should do.
Design and implementation: defining the organization of the system and implementing the system.
Validation: checking that it does what the customer wants.
Evolution: changing the system in response to changing customer needs.
Plan vs. agile processes
Plan driven processes are processes where all the process activities are planned in advance and progress is measured against this plan.
In agile processes, planning is incremental, and it is easier to change the process to reflect changing customer requirements.
There are no right or wrong software processes.
Waterfall
Iterative
Spiral Rational Unified Process (RUP)
Inception: involves defining the project's scope, critical use cases, and candidate architecture, estimating costs, schedule, and risks, and preparing the project environment
Elaboration: involves defining and validating the architecture, refining the project vision and critical use cases, creating detailed iteration plans for the construction phase, setting up the development environment, and selecting and assessing architectural components to ensure accurate cost and schedule estimates.
Construction: involves the complete component development and testing
Transition: involves deploying and releasing the product SCRUM
How does this work?
The product owner gets feedback from users and defines the features and stories.
The team, scrum master and product owner plan the sprint (1-4 weeks of work).
Each day, the scrum master meets with the team to define the daily goals.
Then, another meeting is done to grow the backlog.
The T, SM, PO and C meet to review the sprint (evaluate the improvement of the product).
A sprint retrospective is done to evaluate the quality of the development system (not the product).
If possible, release the increment to the product
Repeat from 2.
Extreme Programming
While SCRUM focuses on project management and teamwork, extreme programming focuses on code quality and individual programmers' work.
Software Verification & Validation
Verification: the system conforms to its specification
Validation: the system meets the requirements and customer needs
Typical testing stages
Unit testing: Individual components are tested, usually by their developers
Integration testing: Tests integrated components
System testing: The system as a whole is tested, usually by an independent test team
Acceptance testing: The system is tested by the customer to check that the needs are met
UML
A system model is a simplified representation of a system from a certain perspective.
Use Case Diagrams
Shows the relationships between actors (user roles or external systems) and use cases (system functionalities or services as perceived by users).
Documentation template:
Documentation
Description
Name
Name of the actor that initiates the use case.
Actor
Name of the actor that initiates the use case.
Description
Brief description highlighting the utility (possibly including results and responsibilities).
Preconditions
Initial conditions (usually about the initial state of the system and actors and input parameters) to be able to execute the use case successfully.
Postconditions
Effects of use case execution, usually in the form of outputs produced and changes in the state of the system and actors (particularly those not visible in the flow of events).
Normal Flow
Textual description (numbered list) of the of normal events (actions of the system and actors).
Alternative flows and exceptions
Alternative or exceptional flows of events, described in relation to the normal flow.
It can also be written as a user story: As a ... I want ... so that ...
Class Diagrams
Used to organize the vocabulary of the problem domain
ClassNamePackageNameClassPackageNotationDescriptionAssociationGeneralization (extends)DependencyAggregation (parts can exist independently of a wholeComposition (parts only exist within a whole), 0.., 1, 0..1, 1..Multiplicity{constraint} class domain modelEventnamedescriptiondatestartTimefinishTimeticketPrice{The number oftickets sold for anevent cannotexceed itscapacity.}Roomcapacity1Seatnumber1seatsBookingbookingId {unique}bookingDateTimetotalPricepaymentInfocancellationDateTime [0..1]1bookingsTicketticketId {unique}validationTime [0..1]111..tickets<<enumeration>>PointOfSalce<<enum>>InternetTicketDesk1*
Requirements Engineering
It is the process of studying customer and user needs to arrive at a definition of system, hardware, or software requirements.
Types of Requirements:
Functional Requirements describe the functions that the software is to execute (also known as capabilities).
Nonfunctional Requirements are the ones that act to constrain the solution.
Definitions of quality characteristics
Functionality suitability: degree to which a product or system provides functions that meet stated and implied needs when used under specified conditions.
Performance efficiency: performance relative to the amount of resources used under stated conditions.
Reliability: degree to which a system, product, or component performs specified functions under specified conditions for a specified period of time.
Usability: degree to which a product or system can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use.
Compatibility: degree to which a product, system, or component can exchange information with other products, systems or components, and/or perform its required functions, while sharing the same hardware or software environment.
Maintainability: degree of effectiveness and efficiency with which a product or system can be modified by the intended maintainers.
Portability: degree of effectiveness and efficiency with which a system, product, or component can be transferred from one hardware software or other operational or usage environment to another.
Security: degree to which a product or system protects information and data that persons or other products or systems have the degree of data access appropriate to their types and levels of authorization.
Stakeholders are the main sources of requirements: people who will be affected by the system and who have a direct or indirect influence on the elaboration of requirements.
Customers
End users
Managers and others involved in organizational processes influenced by the system
People responsible for maintaining the system
Clients of the organization that may use the system
Regulatory and certification bodies, etc.
User Stories
Lightweight way to record a software need, with just enough information (for prioritization, planning, and initiating conversations).
INVEST:
Independent
Negotiable
Valuable
Estimable
Small
Testable
Acceptance Tests
Test cases defined for customers to decide if a system or feature implementation can be accepted (i.e., satisfies requirements and expectations).
A common format is that of Behavior-Driven-Development (BDD), which are test scenarios specifying expected system behaviors according to the template:
Given [initial context or preconditions]
When [events occur]
Then [ensure some outcomes or postconditions]
VUCA World
Volatility: change is rapid and unpredictable
Uncertainty: the present is unclear, and the future is uncertain
Complexity: many different, interconnected factors come into play, with the potential to cause chaos and confusion
Ambiguity: there is a lack of clarity or awareness about what reality is
