Agile Software Development Models

Agile Process Models

• Agile software engineering merges a philosophy with development guidelines
• The philosophy promotes customer satisfaction through early software delivery
• Agile favors small, motivated teams and informal methods
• Agile aims for minimal software engineering work and development simplicity
• Development guidelines prioritize delivery over analysis and design
• A key aspect is active communication between developers and customers

Agile Software Development Model Values

• Individuals and interactions are preferred over processes and tools
• Development of working software takes precedence
• Collaboration with the customer or client is essential
• Rapid response to change is valued

Agile vs Waterfall

• Rapid implementation is possible for small projects
• For large projects, the development time is difficult to estimate
• Errors can be addressed during the development process
• Short iterations are preferred, often spanning 2-4 weeks
• Agile development is iterative, with less focus on initial planning
• Documentation has a lower priority compared to coding
• Shippable features are delivered at the end of iterations to the customer in agile testing
• New features are usable immediately after release and are useful with good customer contact
• Testers and developers have a close working relationship
• User acceptance is performed at the end of every sprint
• Requires close communication and joint analysis of requirements by developers along with the customer
• The waterfall model develops software sequentially from start to finish
• The design phase is not broken down into individual models
• The customer can only see the final product
• Waterfall development is more structured and secure
• Project estimates can be completed for all project types
• The entire product is tested only at the end
• Fixing errors require restarting the project in waterfall
• The waterfall process is phased, with larger phases than agile's iterations
• Each phase includes a detailed description of the next phase
• Documentation is a high priority for training and upgrades
• All developed features are delivered after a long implementation phase
• Testers work independent of developers
• User acceptance occurs only at the end
• Developers are not involved in planning, leading to time delays

Advantages of Agile

• Produces customer satisfaction through continuous delivery
• Emphasizes people, interactions, constant communication
• Delivers working software frequently
• Face-to-face conversation is the best form of communication
• Enables close cooperation between business people and developers on a daily basis
• Adapts to changing circumstances and supports late requirement changes

Disadvantages of Agile

• Assessing required effort for large software deliverables is difficult in the initial phase
• Lacks the importance of design and documentation
• Unclear customer direction can derail the project
• Requires senior programmers, with limited room for new programmers

When to use Agile

• When changes need to be made easily
• To implement a new feature, agile gives the opportunity to roll back fast
• Greater freedom for developers and stakeholders
• Options allow decisions to until more or better data becomes available: and keep the project flowing

Introduction to UML

• UML helps to model object-oriented designs
• UML is a graphical language for communicating software designs
• UML is a standard notation for object-oriented design

Motivations for UML

• UML combines ideas from multiple modeling languages
• UML provides a modeling language to develop correct designs
• UML requires a modeling language to develop efficient designs
• UML needs to communicate with project stakeholders

UML Implementation

• UML allows specification of user/system interactions
• UML allows specification of partitioning of responsibility in OO
• UML allows specification of integration with larger systems
• UML allows specification of concurrent operations
• UML allows specification of operation orderings (algorithms)
• UML is not a process, and does not tell people what to do
• UML is language independent
• UML diagrams use specific icons and notations

Types of UML diagrams

• Use case diagrams
• Class diagrams
• Sequence diagrams
• Package diagrams
• State diagrams
• Activity diagrams
• Deployment diagrams

UML Breakdown

• Model 80% of problems through 20% of the UML

Use Case Diagrams

• Describe functional system behavior from the user perspective

Class Diagrams

• Represent the system's static structure

Sequence Diagrams

• Describe dynamic system behavior

Statechart Diagrams

• Describe dynamic behavior of individual components, essentially a finite state automaton

Activity Diagrams

• Model the system's dynamic behavior as a workflow

UML Syntax

• UML actors show the interface with the system, to group system interactions
• Actors are external
• UML boxes display groupings of elements
• Arrows convey flow, dependency, or generalization

Use Case Diagrams

• Used to depict external behavior
• Used for requirements elicitation
• Display external behavior
• The use case represents roles of interactions of a system
• The set is a complete description for all functions

Actors

• Model external entities that are communicating with the system
• Actors can have unique names and descriptions in the system
• Examples include people on trains, GPS satellites
• Actors model external systems
• Actors model physical environments

Use Case Details

• A use case represents a function in a system as an event flow
• Includes unique name, associated actors, entry/exit condidtions

UML and Modeling

• Use case diagrams represent external behavior
• Use case descriptions provide meat of the model
• Use cases should be described for model use

UML: Constraints

• Constraints allow notation of arbitrary constraints on elements

UML: Stereotypes

• Stereotypes extend the semantics of UML through a word/phrase
• These stereotypes should be consistently applied

UML: Use Cases

• A use case encodes the user interactions
• Captures user-visible functions
• Achieves some goal for the user

Class Diagrams

• These are motivated by the object-oriented paradigm (OOD, OOP)
• Diagrams are to partition the system into areas
• Diagrams are to show dependencies between them

Types of Classes

• An actor is outside the system that interacts with the system; Passengers
• A class models the entity inside the system; User
• Object is a specific instance of a class

Class Diagrams Perspective

• Conceptual diagrams represent the project domains
• Specification displays the interface between components of the software
• Diagrams correspond to Java and C++

UML: Class Diagrams

• Diagrams portray the class structure
• Can show the concept, the attribute, and the operations
• Class diagrams structure the concepts for the system

UML: Cardinality

• Cardinality indicates relationships numerically

Example Relationships

• One class has one capital city relationship.
• A Stock Exchange manages many Companies
• A Company can be on any Stock Exchange.

UML: Aggregation

• Aggregation is a special case that shows a "consists of" relationship

Aggregation

• Aggregation implies a separate child that exists independently to the parent
• Composition implies the separate child cannot exists independent to the parent

UML: Inheritance

• Children inherit parent attributes/operations
• Simplifies the model

Package Diagrams

• Package diagrams reveals the dependencies between them
• A "package" is related classes and its class diagram
• Packages interact through defined interfaces - There is no data sharing, and code sharing
• Not all packages are new software within the model
• Often, they are already available in terms of software