Software Engineering

What is a Project?

A project is a temporary endeavor undertaken to create a unique

product, service, or result.

A project is a series of structured tasks, activities, and deliverables

that are carefully executed to achieve a desired outcome.

Here are some examples of projects:

​ Video game development

​ Building construction
​ Natural disaster relief efforts
Some of the most common names for these phases
include:
​ Feasibility — Determines if the business case is valid
and if the organization has the capability to deliver
the intended outcome.
​ Design — Planning and analysis lead to the design of
a project’s deliverable(s).
​ Build — Construction of the deliverable(s) with
integrated quality assurance activities.
​ Test — Final quality review and inspection of deliverables are
carried out before transition, go-live, or customer
acceptance.
​ Deploy — Project deliverables are put into use and
transitional activities required for sustainment, benefits
realization, and organizational change management are
completed.
​ Close — The project is closed, project knowledge and
artifacts are archived, project team members are released,
and contracts are closed.
Below is a cartoon depicting the state of the project with poor
communication, inadequate management, improper s/w process
f/w follow ups, etc..

How the customer explained it

how the Project leader understood it
how the analyst designed it
how they programmer wrote it
how the business consultant described it
how the project was a documented

what operations installed

how the customer was billed
how it was supported

what the customer really needed

Applications in Software Engineering
Unified Modeling Language (UML) is a versatile tool used in software engineering for

visualizing, specifying, constructing, and documenting software systems. It is widely

applied in various domains such as enterprise information systems, banking,

telecommunications, defense, and web-based services. UML is particularly useful in

modeling both software and non-software systems, including workflows in legal systems

and healthcare systems.

wikipedia.org

In software engineering, UML helps in creating class diagrams, component

diagrams, deployment diagrams, and use case diagrams to represent the static and

dynamic aspects of systems. These diagrams facilitate better understanding and

communication among stakeholders, making the development process more efficient.

UML also supports object-oriented analysis and design, which is crucial for developing complex
software systems.

UML is a notation that resulted from the unification of

1.​Object Modeling Technique OMT [James Rumbaugh 1991] - was
best for analysis and data-intensive information systems.

2.​Booch [Grady Booch 1994] - was excellent for design and

implementation. Grady Booch had worked extensively with the
Ada language, and had been a major player in the development
of Object Oriented techniques for the language. Although the
Booch method was strong, the notation was less well received
(lots of cloud shapes dominated his models - not very tidy)
3.​OOSE (Object-Oriented Software Engineering [Ivar Jacobson
1992]) - featured a model known as Use Cases. Use Cases are a
powerful technique for understanding the behaviour of an
entire system.

Why UML
As the strategic value of software increases for many companies, the industry looks for

techniques to automate the production of software and to improve quality and reduce

cost and time-to-market. These techniques include component technology, visual

programming, patterns and frameworks. Businesses also seek techniques to manage

the complexity of systems as they increase in scope and scale. In particular, they

recognize the need to solve recurring architectural problems, such as physical

distribution, concurrency, replication, security, load balancing and fault tolerance.

Additionally, the development for the World Wide Web, while making some things

simpler, has exacerbated these architectural problems. The Unified Modeling Language

(UML) was designed to respond to these needs. The primary goals in the design of the

UML summarize by Page-Jones in Fundamental Object-Oriented Design in UML as

follows:

1.​ Provide users with a ready-to-use, expressive visual modeling language so they
can develop and exchange meaningful models.
2.​ Provide extensibility and specialization mechanisms to extend the core concepts.
3.​ Be independent of particular programming languages and development
processes.
4.​ Provide a formal basis for understanding the modeling language.
5.​ Encourage the growth of the OO tools market.
6.​ Support higher-level development concepts such as collaborations, frameworks,
patterns and components.
7.​ Integrate best practices.

For whom?
A software development will have many stakeholders playing a part.
For Example:

●​ Analysts

●​ Designers

●​ Coders

●​ Testers

●​ QA

●​ The Customer

●​ Technical Authors

Types of UML Diagrams

UML diagrams can be broadly classified into two categories: Structural

Diagrams and Behavioral Diagrams.

Structural UML Diagrams

 1.​ Class Diagram: Depicts the static structure of a system by showing
the system's classes, their methods, and attributes. It helps identify
relationships between different classes or objects.
2.​ Composite Structure Diagram: Represents the internal structure of
a class and its interaction points with other parts of the system.
3.​ Object Diagram: Shows instances of classes in the system and their
relationships at a particular instant.
4.​ Component Diagram: Represents how the physical components in a
system have been organized and helps in modeling implementation
details.
5.​ Deployment Diagram: Illustrates system hardware and software
components and their distribution over multiple machines.
6.​ Package Diagram: Depicts how packages and their elements have
been organized, showing dependencies between different packages.

Behavioral UML Diagrams

1.​ State Machine Diagrams: Represent the condition of the system at

finite instances of time, modeling the dynamic behavior of a class in
response to time and changing external stimuli.
2.​ Activity Diagrams: Illustrate the flow of control in a system, depicting
workflows visually.
3.​ Use Case Diagrams: Depict the functionality of a system or a part of
a system, illustrating functional requirements and interactions with
external agents.
4.​ Sequence Diagrams: Depict interaction between objects in a
sequential order, showing how and in what order the objects in a
system function.
5.​ Communication Diagrams: Show sequenced messages exchanged
between objects, focusing on objects and their relationships.
6.​ Timing Diagrams: Depict the behavior of objects over a time frame,
showing time and duration constraints.
7.​ Interaction Overview Diagrams: Model a sequence of actions,
simplifying complex interactions into simpler occurrences.

Benefits of Using UML Diagrams

 ●​ Standardization: Provides a standardized way of representing
system models, ensuring clear communication among developers and
stakeholders.
●​ Communication: Serves as a powerful communication tool
between stakeholders, helping convey complex ideas in an
understandable manner.
●​ Visualization: Facilitates the visualization of system components,
relationships, and processes, aiding in understanding and designing
complex systems.

●​ Documentation: Acts as effective documentation tools, providing a

structured way to document various aspects of a system.
●​ Analysis and Design: Supports both analysis and design phases of
software development, helping model requirements and transform
them into implementable designs.

Tools for Creating UML Diagrams

Several tools are available for creating UML diagrams, including:

●​ Lucidchart: A web-based diagramming tool that supports UML

diagrams and allows real-time collaboration.
●​ Draw.io: A free, web-based diagramming tool that integrates with
various cloud storage services.
●​ Visual Paradigm: Provides a comprehensive suite of tools for
software development, supporting a wide range of UML diagrams.
●​ StarUML: An open-source UML modeling tool with a user-friendly
interface.
●​ Papyrus: An open-source UML modeling tool that is part of the
Eclipse Modeling Project.
●​ PlantUML: A text-based tool that allows creating UML diagrams using
a simple and human-readable syntax.

By integrating UML into your workflow, you can create more comprehensive and communicative

system models, improving the quality and clarity of your software designs12.
What is a Class Diagram?
The class diagram is a central modeling technique that runs through nearly all

object-oriented methods. This diagram describes the types of objects in the system and

various kinds of static relationships which exist between them.

Relationships

There are three principal kinds of relationships which are important:

1.​ Association - represent relationships between instances of types (a person

works for a company, a company has a number of offices.

2.​ Inheritance - the most obvious addition to ER diagrams for use in OO. It has an

immediate correspondence to inheritance in OO design.

3.​ Aggregation - Aggregation, a form of object composition in object-oriented

design.
Class Diagram Example
The following Class Diagram example represents two classes - User and

Attachment. A user can upload multiple attachments so the two classes are

connected with an association, with 0..* as multiplicity on the Attachment side.

Package Diagram
Package diagram is UML structure diagram which shows packages and dependencies

between the packages. Model diagrams allow to show different views of a system, for

example, as multi-layered (aka multi-tiered) application - multi-layered application

model.

Component Diagram
In the Unified Modeling Language, a component diagram depicts how

components are wired together to form larger components or software systems.

It illustrates the architectures of the software components and the dependencies

between them. Those software components including run-time components,

executable components also the source code components

Deployment Diagram
The Deployment Diagram helps to model the physical aspect of an Object-Oriented

software system. It is a structure diagram which shows architecture of the system as

deployment (distribution) of software artifacts to deployment targets.

Use Case Diagram
A use-case model describes a system's functional requirements in terms of

use cases. It is a model of the system's intended functionality (use cases)

and its environment (actors). Use cases enable you to relate what you

need from a system to how the system delivers on those needs.

Think of a use-case model as a menu, much like the menu you'd find in a

restaurant. By looking at the menu, you know what's available to you, the

individual dishes as well as their prices. You also know what kind of cuisine

the restaurant serves: Italian, Mexican, Chinese, and so on. By looking at

the menu, you get an overall impression of the dining experience that
awaits you in that restaurant. The menu, in effect, "models" the restaurant's

behavior.

Because it is a very powerful planning instrument, the use-case model is

generally used in all phases of the development cycle by all team

members.

Activity Diagram
Activity diagrams are graphical representations of workflows of stepwise activities and

actions with support for choice, iteration and concurrency.

Sequence Diagram
The Sequence Diagram models the collaboration of objects based on a time sequence.

It shows how the objects interact with others in a particular scenario of a use case. With

the advanced visual modeling capability, you can create complex sequence diagram in

few clicks. Besides, some modeling tool such as Visual Paradigm can generate

sequence diagram from the flow of events which you have defined in the use case

description.
UML Terms
●​ Abstract Class - A class that will never be instantiated. An instance of this

class will never exist.

●​ Actor - An object or person that initiates events the system is involved

with.

●​ Activity: A step or action within an Activity Diagram. Represents an action

taken by the system or by an Actor.

●​ Activity Diagram: A glorified flowchart that shows the steps and decisions

and parallel operations within a process, such as an algorithm or a

business process.

●​ Aggregation - Is a part of another class. Shown with a hollow diamond

next to the containing class in diagrams.

●​ Artifacts - Documents describing the output of a step in the design

process. The description is graphic, textual, or some combination.

●​ Association - A connection between two elements of a Model. This might

represent a member variable in code, or the association between a

personnel record and the person it represents, or a relation between two

categories of workers, or any similar relationship. By default, both elements

in an Association are equal, and are aware of each other through the

Association. An Association can also be a Navigable Association, meaning

that the source end of the association is aware of the target end, but not

vice versa.

●​ Association Class: A Class that represents and adds information to the

Association between two other Classes.

●​ Attributes - Characteristics of an object which may be used to reference

other objects or save object state information.

●​ Base Class: A Class which defines Attributes and Operations that are

inherited by a Subclass via a Generalization relationship.

●​ Branch: A decision point in an Activity Diagram. Multiple Transitions

emerge from the Branch, each with a Guard Condition. When control
 reaches the Branch, exactly one Guard Condition must be true; and control

follows the corresponding Transition.

●​ Class: A category of similar Objects, all described by the same Attributes

and Operations and all assignment-compatible.

●​ Class Diagram - Shows the system classes and relationships between

them.

●​ Classifier: A UML element that has Attributes and Operations. Specifically,

Actors, Classes, and Interfaces.

●​ Collaboration: A relation between two Objects in a Communication

Diagram, indicating that Messages can pass back and forth between the

Objects.

●​ Communication Diagram - A diagram that shows how operations are

done while emphasizing the roles of objects.

●​ Component: A deployable unit of code within the system.

●​ Component Diagram: A diagram that shows relations between various

Components and Interfaces.

●​ Concept - A noun or abstract idea to be included in a domain model.

●​ Construction Phase - The third phase of the Rational Unified Process

during which several iterations of functionality are built into the system

under construction. This is where the main work is done.

●​ Dependence: A relationship that indicates one Classifier knows the

Attributes and Operations of another Classifier, but isn't directly connected

to any instance of the second Classifier.

●​ Deployment Diagram: A diagram that shows relations between various

Processors.

●​ Domain -The part of the universe that the system is involved with.

●​ Elaboration Phase - The second phase of the Rational Unified Process

that allows for additional project planning including the iterations of the

construction phase.

●​ Element: Any item that appears in a Model.

●​ Encapsulation - Data in objects is private.

●​ Generalization - Indicates that one class is a subclass on another class

(superclass). A hollow arrow points to the superclass.

●​ Event: In a State Diagram, this represents a signal or event or input that

causes the system to take an action or switch States.

●​ Final State: In a State Diagram or an Activity Diagram, this indicates a

point at which the diagram completes.

●​ Fork: A point in an Activity Diagram where multiple parallel control threads

begin.

●​ Generalization: An inheritance relationship, in which a Subclass inherits

and adds to the Attributes and Operations of a Base Class.

●​ GoF - Gang of Four set of design patterns.

●​ High Cohesion - A GRASP evaluative pattern which makes sure the class

is not too complex, doing unrelated functions.

●​ Low Coupling - A GRASP evaluative pattern which measures how much

one class relies on another class or is connected to another class.

●​ Inception Phase - The first phase of the Rational Unified Process that

deals with the original conceptualization and beginning of the project.

●​ Inheritance - Subclasses inherit the attributes or characterics of their

parent (superclass) class. These attributes can be overridden in the

subclass.

●​ Initial State: In a State Diagram or an Activity Diagram, this indicates the

point at which the diagram begins.

●​ Instance - A class is used like a template to create an object. This object is

called an instance of the class. Any number of instances of the class may

be created.

●​ Interface: A Classifier that defines Attributes and Operations that form a

contract for behavior. A provider Class or Component may elect to Realize

an Interface (i.e., implement its Attributes and Operations). A client Class

or Component may then Depend upon the Interface and thus use the

provider without any details of the true Class of the provider.

●​ Iteration - A mini project section during which some small piece of

functionality is added to the project. Includes the development loop of

analysis, design and coding.

●​ Join: A point in an Activity Diagram where multiple parallel control threads

synchronize and rejoin.

●​ Member: An Attribute or an Operation within a Classifier.

●​ Merge: A point in an Activity Diagram where different control paths come

together.
●​ Message - A request from one object to another asking the object

receiving the message to do something. This is basically a call to a method

in the receiving object.

●​ Method - A function or procedure in an object.

●​ Model - The central UML artifact. Consists of various elements arranged in

a hierarchy by Packages, with relations between elements as well.

●​ Multiplicity - Shown in a domain model and indicated outside concept

boxes, it indicates object quantity relationship to quantiles of other objects.

●​ Navigability: Indicates which end of a relationship is aware of the other

end. Relationships can have bidirectional Navigability (each end is aware

of the other) or single directional Navigability (one end is aware of the

other, but not vice versa).

●​ Notation - Graphical document with rules for creating analysis and design

methods.

●​ Note: A text note added to a diagram to explain the diagram in more detail.

●​ Object - Object: In an Activity Diagram, an object that receives information

from Activities or provides information to Activities. In a Collaboration

Diagram or a Sequence Diagram, an object that participates in the

scenario depicted in the diagram. In general: one instance or example of a

given Classifier (Actor, Class, or Interface).

●​ Package - A group of UML elements that logically should be grouped

together.
●​ Package Diagram: A Class Diagram in which all of the elements are

Packages and Dependencies.

●​ Pattern - Solutions used to determine responsibility assignment for objects

to interact. It is a name for a successful solution to a well-known common

problem.

●​ Parameter: An argument to an Operation.

●​ Polymorphism - Same message, different method. Also used as a

pattern.

●​ Private: A Visibility level applied to an Attribute or an Operation, indicating

that only code for the Classifier that contains the member can access the

member.

●​ Processor: In a Deployment Diagram, this represents a computer or other

programmable device where code may be deployed.

●​ Protected: A Visibility level applied to an Attribute or an Operation,

indicating that only code for the Classifier that contains the member or for

its Subclasses can access the member.

●​ Public: A Visibility level applied to an Attribute or an Operation, indicating

that any code can access the member.

●​ Reading Direction Arrow - Indicates the direction of a relationship in a

domain model.

●​ Realization: Indicates that a Component or a Class provides a given

Interface.
●​ Role - Used in a domain model, it is an optional description about the role

of an actor.

●​ Sequence Diagram: A diagram that shows the existence of Objects over

time, and the Messages that pass between those Objects over time to

carry out some behavior. State chart diagram - A diagram that shows all

possible object states.

●​ State: In a State Diagram, this represents one state of a system or

subsystem: what it is doing at a point in time, as well as the values of its

data.

●​ State Diagram: A diagram that shows States of a system or subsystem,

Transitions between States, and the Events that cause the Transitions.

●​ Static: A modifier to an Attribute to indicate that there's only one copy of

the Attribute shared among all instances of the Classifier. A modifier to an

Operation to indicate that the Operation stands on its own and doesn't

operate on one specific instance of the Classifier.

●​ Stereotype: A modifier applied to a Model element indicating something

about it which can't normally be expressed in UML. In essence,

Stereotypes allow you to define your own "dialect" of UML.

●​ Subclass: A Class which inherits Attributes and Operations that are

defined by a Subclass via a Generalization relationship.

●​ Swimlane: An element of an Activity Diagram that indicates what parts of a

system or a domain perform particular Activities. All Activities within a

 Swimlane are the responsibility of the Object, Component, or Actor

represented by the Swimlane.

●​ Time Boxing - Each iteration will have a time limit with specific goals.

●​ Transition: In an Activity Diagram, represents a flow of control from one

Activity or Branch or Merge or Fork or Join to another. In a State Diagram,

represents a change from one State to another.

●​ Transition Phase - The last phase of the Rational Unified Process during

which users are trained on using the new system and the system is made

available to users.

●​ UML - Unified Modeling Language utilizes text and graphic documents to

enhance the analysis and design of software projects by allowing more

cohesive relationships between objects.

●​ Use Case: In a Use Case Diagram, represents an action that the system

takes in response to some request from an Actor.

●​ Use Case Diagram: A diagram that shows relations between Actors and

Use Cases.

●​ Visibility: A modifier to an Attribute or Operation that indicates what code

has access to the member. Visibility levels include Public, Protected, and

Private.

●​ Workflow - A set of activities that produces some specific result.

The UML Class diagram is a graphical notation used to construct and visualize object

oriented systems. A class diagram in the Unified Modeling Language (UML) is a type of

static structure diagram that describes the structure of a system by showing the

system's:

●​ classes,

●​ their attributes,

●​ operations (or methods),

●​ and the relationships among objects.

Example

A dog has states - color, name, breed as well as behaviors -wagging, barking, eating.

An object is an instance of a class.

UML Class Notation
A class represents a concept which encapsulates state (attributes) and behavior

(operations). Each attribute has a type. Each operation has a signature. The class

name is the only mandatory information.

Class Name:

●​ The name of the class appears in the first partition.

Class Attributes:

●​ Attributes are shown in the second partition.

●​ The attribute type is shown after the colon.

●​ Attributes map onto member variables (data members) in code.

Class Operations (Methods):

●​ Operations are shown in the third partition. They are services the class provides.

●​ The return type of a method is shown after the colon at the end of the method

signature.

●​ The return type of method parameters are shown after the colon following the

parameter name. Operations map onto class methods in code

●​
Class Visibility

The +, - and # symbols before an attribute and operation name in a class denote the

visibility of the attribute and operation. ~ for default accessibility)

●​ + denotes public attributes or operations

●​ - denotes private attributes or operations

●​ # denotes protected attributes or operations

●​ ~ denotes package/default attributes or operations

Perspectives of Class Diagram

The choice of perspective depends on how far along you are in the development

process. During the formulation of a domain model, for example, you would seldom

move past the conceptual perspective. Analysis models will typically feature a mix of

conceptual and specification perspectives. Design model development will typically

start with heavy emphasis on the specification perspective, and evolve into the

implementation perspective.
A diagram can be interpreted from various perspectives:

●​ Conceptual: represents the concepts in the domain

●​ Specification: focus is on the interfaces of Abstract Data Type (ADTs) in the

software

●​ Implementation: describes how classes will implement their interfaces

The perspective affects the amount of detail to be supplied and the kinds of

relationships worth presenting. As we mentioned above, the class name is the only

mandatory information.

Relationships between classes

UML is not just about pretty pictures. If used correctly, UML precisely conveys how code

should be implemented from diagrams. If precisely interpreted, the implemented code

will correctly reflect the intent of the designer. Can you describe what each of the

relationships mean relative to your target programming language shown in the Figure

below?

If you can't yet recognize them, no problem this section is meant to help you to

understand UML class relationships. A class may be involved in one or more

relationships with other classes. A relationship can be one of the following types:
Inheritance (or Generalization):

A generalization is a taxonomic relationship between a more general classifier and a

more specific classifier. Each instance of the specific classifier is also an indirect

instance of the general classifier. Thus, the specific classifier inherits the features of the

more general classifier.

●​ Represents an "is-a" relationship.

●​ An abstract class name is shown in italics.

●​ SubClass1 and SubClass2 are specializations of SuperClass.

The figure below shows an example of inheritance hierarchy. SubClass1 and

SubClass2 are derived from SuperClass. The relationship is displayed as a solid line

with a hollow arrowhead that points from the child element to the parent element.
Association

Associations are relationships between classes in a UML Class Diagram. They are

represented by a solid line between classes. Associations are typically named using a

verb or verb phrase which reflects the real world problem domain.

Simple Association

●​ A structural link between two peer classes.

●​ There is an association between Class1 and Class2

The figure below shows an example of simple association. There is an association that

connects the <<control>> class Class1 and <<boundary>> class Class2. The

relationship is displayed as a solid line connecting the two classes.

Cardinality

Cardinality is expressed in terms of:

●​ one to one

●​ one to many

●​ many to many

Aggregation

A special type of association.

●​ It represents a "part of" relationship.

●​ Class2 is part of Class1.

●​ Many instances (denoted by the *) of Class2 can be associated with Class1.

●​ Objects of Class1 and Class2 have separate lifetimes.

Composition

●​ A special type of aggregation where parts are destroyed when the whole is

destroyed.

●​ Objects of Class2 live and die with Class1.

●​ Class2 cannot stand by itself.

The figure below shows an example of composition. The relationship is displayed as a

solid line with a filled diamond at the association end, which is connected to the class

that represents the whole or composite.

Dependency

An object of one class might use an object of another class in the code of a method. If

the object is not stored in any field, then this is modeled as a dependency relationship.

●​ A special type of association.

●​ Exists between two classes if changes to the definition of one may cause

changes to the other (but not the other way around).

●​ Class1 depends on Class2

Below shows an example of dependency. The relationship is displayed as a dashed line

with an open arrow.

Realization

Realization is a relationship between the blueprint class and the object containing its

respective implementation level details. This object is said to realize the blueprint class.

In other words, you can understand this as the relationship between the interface and

the implementing class.

For example, the Owner interface might specify methods for acquiring property and

disposing of property. The Person and Corporation classes need to implement these

methods, possibly in very different ways.

Class Attributes: properties

Methods:

Abstraction
Let us start with abstraction.
Abstraction uses symbols << xxxxxx >>
Abstract is DRY
Association
It is a typr of relationship. Not the dependency

Aggregation
A spl. Type of association. A hollow diamond
Turtle → creep

Composition
A Solid diamond

Multiplicity
Class Diagram Example: Order System
Example: GUI
Student Administration system:

The student administration system:

Student management Class diagrams describe the structure of a student
management system classes, operations and relationships among the
objects.
The main classes of student management system are student, fees, logins,
profiles, courses and exams
Classes Student management system
class diagrams:
●​ Student class: manage all the operations of student
●​ Fees class : manage all the operations of Fees.
●​ Logins class: manage all the operations of logins.
●​ Profiles class : manage all the operations of a profiles
●​ Courses class : manage all the operations of courses
●​ Exams class: manage all the operations of exams.
Classes and their attributes of student Administration system
student attributes: student_id, student_college_ID, student_name,
mobile_number, emailId, username, password
Fees attributes: fee_ID, fee_course_ID, fee_amount, total, fee payment,
free type, description
Logins attributes: login ID, login user ID, login role ID, login username,
login password, login last login
profiles attributes: profile ID profile name, profile type, profile description
course attributes: course_ID, Course_student_id course_registration,
course_name, course_type, course_year, course_description
exams attributes: exam_ID, exam_student_id, exam_HTicket_number,
exam_date, exam_name, exam_type, exam_description

Classes and their methods

Student operations: addStudent(), editStudent(), deleteStudent(),
updateStudent(), saveStudent(), Searchstudent()
Fees operations: editFees(), deleteFees(), addFees(), saveFees(),
searchFees(),UpdateFees()
courses operations: addCourses(), deleteCourses(),
searchCourses(),saveCourses(), updateCourses()
Logins operations: editLogins(),addLogins(), SaveLogins(),
updateLogins(), searchLogins(),
profiles operations: deleteProfiles(), addProfiles(), editProfiles(),
saveProfiles(), updateProfiles(), searchProfiles()
Exams operations: updateExams() editExams(), deleteExams(),
addExams(), saveExams(), searchExams()
Software Process Framework Framework
Software Process Framework Framework is a Standard way to build and deploy applications.
Software Process Framework is a foundation of complete software engineering process.
Software process framework includes all set of umbrella activities. It also includes a number of
framework activities that are applicable to all software projects.

A generic process framework encompasses five activities which are given below one by one:

1. Communication: In this activity, heavy communication with customers and other

stakeholders, requirement gathering is done.
2. Planning: In this activity, we discuss the technical related tasks, work schedule, risks,
required resources etc.
3. Modeling: Modelling is about building representations of things in the ‘real world’.In
modelling activity, a product’s model is created in order to better understand and requirements.
4. Construction: In software engineering, construction is the application of a set of procedures
that are needed to assemble the product. In this activity, we generate the code and test the
product in order to make a better product.
5. Deployment: In this activity, a complete or in-complete products or software are represented
to the customers to evaluate and give feedback. On the basis of their feedback we modify the
products to supply better products.

Umbrella activities include:

• Riskmanagement
• Software quality assurance(SQA)
• Software configuration management(SCM)
• Measurement
• Formal technical reviews(FTR)

Umbrella Activities are as follows:

1. Software Project Tracking and Control
2. Formal Technical Reviews
3. Software Quality Assurance of software development.
4. Software Configuration Management
5. Document Preparation and Production
6. Re-usability Management
7. Measurement and Metrics
8. Risk Management
ISO 9000
ISO (International Standards Organization) is a group or consortium of 63
countries established to plan and foster standardization. ISO declared its
9000 series of standards in 1987.
●​ It serves as a reference for the contract between independent parties.
●​ This standard determines the guidelines for maintaining a quality
system. This standard mainly addresses operational methods and
organizational methods such as responsibilities, reporting, etc.
●​ This defines a set of guidelines for the production process and is not
directly concerned about the product itself.

The ISO 9000 series of standards is based on the assumption that if a

proper stage is followed for production, then good quality products are
bound to follow automatically. The types of industries to which the various
ISO standards apply are as follows.

1. ISO 9001: This standard applies to the organizations engaged in design,

development, production, and servicing of goods. This is the standard
that applies to most software development organizations.
2. ISO 9002: This standard applies to those organizations which do not
design products but are only involved in the production. Examples of these
category industries contain steel and car manufacturing industries that buy
the product and plant designs from external sources and are engaged in
only manufacturing those products. Therefore, ISO 9002 does not apply to
software development organizations.

3. ISO 9003: This standard applies to organizations that are involved only
in the installation and testing of the products. For example, Gas companies.

Why ISO Certification required by the Software Industry?

There are several reasons why software industry must get an ISO
certification. Some of reasons are as follows:

1.​ It helps in designing high-quality repeatable software products.

2.​ It emphasizes the need for proper documentation.
3.​ It facilitates development of optimal processes and totally quality
measurements.

Features of ISO 9001 Requirements:

Document control –
All documents concerned with the development of a software product
should be properly managed and controlled.
Planning –
Proper plans should be prepared and monitored.
Review –
For effectiveness and correctness all important documents across all
phases should be independently checked and reviewed .
Testing –
The product should be tested against specification.
Organizational Aspects –
Various organizational aspects should be addressed e.g., management
reporting of the quality team.
Advantages of ISO 9000 Certification :

➢​Each procedure and work instruction must be documented and thus

becomes a springboard for continuous improvement.
➢​Employees morale is increased as they’re asked to require control of
their
➢​processes and document their work processes
➢​Better products and services result from continuous improvement
➢​process.
➢​Increased employee participation, involvement, awareness and
➢​systematic employee training reduces problems.

CMM(The Capability Maturity Model ) Process

Patterns

CMM is similar to ISO 9001, one of the ISO 9000 series of standards
specified by the International Organization for Standardization. The ISO
9000 standards specify an effective quality system for manufacturing and
service industries; ISO 9001 deals specifically with software development
and maintenance.

CMM is more detailed and specific than ISO 9001

The main difference between CMM and ISO 9001 lies in their respective
purposes: ISO 9001 specifies a minimal acceptable quality level for
software processes, while CMM establishes a framework for continuous
process improvement. It is more explicit than the ISO standard in defining
the means to be employed to that end. Emphasizing

The Software Engineering Institute (SEI) Capability Maturity Model (CMM)

specifies an increasing series of levels of a software development
organization. The higher the level, the better the software development
process, hence reaching each level is an expensive and time-consuming
process.

CMM's five levels of maturity for software processes

There are five levels to the CMM development process. They are the
following:

1.​ Initial (Level 1). At the initial level, processes are disorganized, ad
hoc and even chaotic. Success likely depends on individual efforts
and is not considered to be repeatable. Defined processes and
standard practices that exist are abandoned during a crisis. Success

of the organization majorly depends on an individual effort,

talent.This is because processes are not sufficiently defined and

documented to enable them to be replicated.

2.​ Repeatable (Level 2). track cost, schedule, and functionality. The
process is in place to repeat the earlier successes on projects with

similar applications. At the repeatable level, requisite processes are

established, defined and documented. As a result, basic project

management techniques are established, and successes in key
process areas are able to be repeated.
3.​ Defined (Level 3). At the defined level, an organization develops its
own standard software development process. These defined
 processes enable greater attention to documentation,
standardization and integration. In thi level, we have documented,
standardized, and integrated into a standard software process for

the entire organization and all projects across the organization use

an approved

4.​ Managed (Level 4). At the managed level, an organization monitors

and controls its own processes through data collection and analysis.
organization set a quantitative quality goal for both software

process and software maintenance

5.​ Optimizing (Level 5). At the optimization level, processes are

constantly improved through monitoring feedback from processes
and introducing innovative processes and functionality. At this level,
changes to the process are to improve the process performance and

at the same time maintaining statistical probability to achieve the

established quantitative process-improvement objectives.

One criticism of CMM is that it is too process-oriented and not goal-oriented

enough. CMMI is designed to make it easier for businesses to apply the
methodology to specific uses than with CMM.
Process Models

In a typical s/w industry, we follow a process to achieve the goals. Goals

are the expected end result within a time frame, budget and quality.

The following framework activities are carried out irrespective of the process

model chosen by the organization.

1. Communication
2. Planning
3. Modeling
4. Construction
5. Deployment

Requirements Document
S/w requirements document or S/w requirements specification
Includes 2 types of the specs. template
1.​ Functional requirements are product features that developers must
implement to enable the users to achieve their goals, i.e., function to meet
the ends. For example, ‘The system must send a confirmation email
whenever an order is placed.’ is a functional requirement.
2.​ Non-functional requirements detail how it will do it and, therefore, must be
included in SRD. If the functional requirement was, ‘The system must send
a confirmation email whenever an order is placed,’ the non-functional
requirement would be, ‘When the payment is complete, the email should
go within 2 seconds.’

Rules:
Keep it organized and professional
Make requirements testable
Apply implementation-neutral functional requirements
Evaluate documentation with stakeholders
Here is a model or template of of an example RDS
Prescriptive process models
Below are some of the types of prescriptive process models:
●​ The Waterfall Model
●​ Incremental Process model

1.Waterfall Model

It's often cited as the first software development methodology.

Dr. Winston W. Royce at the Lockheed Software Technology Center

introduced this concept in 1970 based on his experience developing software
for satellites. The model is also used more generally as a high-level project
management methodology for complicated, multifaceted projects.

The Waterfall model is a linear, sequential approach to the software

development lifecycle (SDLC) that's popular in software engineering and
product development.

The Waterfall model uses a logical progression of SDLC steps for a project,
similar to the direction water flows over the edge of a cliff. It sets distinct
endpoints or goals for each phase of the development process. Those
endpoints or goals can't be revisited after their completion.

Who uses the Waterfall model?

Project teams and project managers use the Waterfall model to achieve goals
based on the needs of their business. The model is used in many different
project management contexts, such as in construction, manufacturing, IT and
software development.
In the Waterfall methodology, each step is dependent on the output of the
previous step. There's a linear progression to the way these projects unfold.

For example, in construction, these three general steps are usually followed:

1.​ A building's physical design is created before any construction

begins.
2.​ The foundation is poured before the skeleton of a building is erected.
3.​ The skeleton of the building is completed before the walls are built.

The Waterfall model doesn't include a project's end users or clients as much
as other development methodologies. Users are consulted during the initial
stages of gathering and defining requirements, and client feedback is
incorporated after that. By leaving the client out of the main part of the
Waterfall process, the development team moves quickly through the phases of
a project.

This methodology is good for teams and projects that want to develop
a project according to fixed or unchanging requirements set forth at
the beginning of the project. Waterfall projects have a high degree of
process definition with little or no output variability. Waterfall is also a
good choice if the project has cost or time constraints.
Projects based on the Waterfall method are well defined, are predictable and
have specific documentation. They have the following characteristics: fixed
requirements, ample resources, an established timeline and well-understood
technology. They usually aren't likely to require significant changes.

Waterfall aims to achieve its goals on the first try. So, in software development
processes, if an application must work out of the box immediately at the risk of
losing customers or some other serious issue, Waterfall is a suitable method.

Phases of the Waterfall model

When used for complex projects, such as software development, the Waterfall
development methodology has seven stages:

1.​ Requirements. Potential project requirements, deadlines and

guidelines for the project are analyzed and placed into a formal
requirements document, also called a functional specification. This
first phase of development defines and plans the project without
mentioning specific processes. It also defines the project scope,
team members, stakeholders, process for requirements gathering,
reporting of project progress, use of aids such as templates and
workflow diagrams, and an overall roadmap of the project.
2.​ Analysis. The system specifications are analyzed to generate
product models and business logic to guide production. This is also
when financial and technical resources are audited for feasibility.
 3.​ Design. A design specification document is created to outline
technical requirements during the design phase. These include the
programming language, hardware, data sources, architecture and
services.
4.​ Coding and implementation. The source code is developed using
the models, logic and requirement specifications designated in the
previous phases. Typically, the system is coded in smaller
components, or units, before being put together.
5.​ Testing. This is when quality assurance and unit, system and beta
tests identify issues that must be resolved. This forces a repeat of
the coding stage for debugging. If the system passes integration and
testing, the Waterfall process continues forward.
6.​ Operation and deployment. The product or application is deemed
fully functional and is deployed to a live environment.
7.​ Maintenance. Corrective, adaptive and perfective maintenance is
carried out indefinitely to improve, update and enhance the product
and its functionality. This could include releasing patch updates and
new versions.

Before moving to the next phase in the Waterfall process, there's usually a
review and sign-off to ensure all defined goals have been met. For example,
developers ensure each unit of technology is properly integrated in the
implementation phase before moving to the testing phase.
Key note:

Meaning that there is no going back to previous stages once they are
finished, similar to how water flows down a waterfall without going back

up

For whom?

Advantages of the Waterfall model

The Agile methodology is often used in place of the Waterfall model. However,
there are advantages to the Waterfall vs. Agile approaches, such as the
following:

●​ The Waterfall approach lets large or changing teams move toward a

common goal that's been defined in the requirements stage.
●​ It forces a structured, disciplined approach.
●​ It simplifies understanding, following and arranging tasks.
●​ It facilitates departmentalization and managerial control based on the
schedule or deadlines.
●​ It reinforces good coding habits to define before implementing design
and then code.
 ●​ It facilitates early system design and specification changes.
●​ It clearly defines milestones and deadlines.

Disadvantages of the Waterfall model

Disadvantages of the Waterfall model typically center around the risk

associated with a lack of revision and flexibility. Specific issues include the
following:

●​ Waterfall design isn't adaptive; when a flaw is found, the entire

process often needs to start over.
●​ The methodology doesn't incorporate midprocess user or client
feedback and makes changes based on results.
●​ The Waterfall model delays testing until the end of the development
lifecycle.
●​ It doesn't consider error correction.
●​ It doesn't handle requests for changes, scope adjustments and
updates well.
●​ Waterfall doesn't let processes overlap for simultaneous work on
different phases, reducing overall efficiency.
●​ No working product is available until the later stages of the project
lifecycle.
●​ Waterfall isn't ideal for complex, high-risk ongoing projects.

Waterfall model software and tools

Gantt charts are a common management tool for Waterfall projects. These
charts enable easy visualization of sequential phases, letting project
managers map dependencies and subtasks for each phase of the process.
They also provide a clear view of timelines and deadlines for each phase.

The basic methodology of this model is that the software development process is
divided into different phases and the next phase can only begin after finishing the
previous one, making it sequential. Requirement analysis, designing, development,
testing, deployment, and maintenance are the different phases of this model.

It is a basic model, every stage is defined clearly, every step is well documented, and
is suitable for small projects. Limitations: The first one is that there is very little scope
of flexibility for error correction.

If any mistake happens between the phases, there is no way to fix it until the entire
process is complete. Moreover, there is no provision to skip, reverse or overlap any
stages. Due to these reasons, this model is proven to be expensive and tedious.

2.Incremental Process Model

The incremental model in software engineering is a modern approach to

project management that involves dividing a complex project into smaller,
self-contained modules known as increments.

Each increment represents a partial system with added functionality, allowing

for the project's gradual development. The key feature of this model is its
iterative process, where increments are developed, tested, and integrated one
after another into the evolving system. This iterative approach facilitates
frequent testing, quick feedback, and early defect detection.

By breaking the project into increments, teams can prioritize features and
address changes efficiently. This process promotes collaboration and
adaptability, making it essential for effectively managing intricate projects in
today's dynamic digital landscape. Continuous assessment, feedback, and
adjustments are integral to this model, enabling prompt identification and
correction of errors. To ensure the smooth integration of increments, careful
planning and coherent design are crucial.
Phases of Incremental Model

The phases of the incremental model typically include:

●​ Requirements Gathering: In this initial phase, the high-level requirements for the
software are gathered and analyzed. These requirements serve as a foundation
for the subsequent phases.
●​ Design: Based on the gathered requirements, the software's architecture,
design, and user interfaces are planned and developed. The design is often
divided into smaller segments to ensure a focused and organized development
process.
●​ Implementation: Each increment involves implementing a portion of the
software's functionality. Developers work on adding features, modules, or
components that were planned in the design phase. This incremental approach
allows for quicker delivery of usable software.
●​ Testing: As each increment is completed, testing is carried out to ensure that the
new features work as expected and do not negatively impact the existing
 functionality. This ongoing testing helps catch and address issues early in the
development process.
●​ Integration: In this phase, the newly developed increments are integrated into
the existing software. This can involve merging code, resolving conflicts, and
ensuring that all components work together smoothly.
●​ Evaluation and Feedback: After each increment, stakeholders review the
functionality added and provide feedback. This feedback can be used to refine
the requirements, design, and implementation of subsequent increments.
●​ Iterative Process: The software development process iterates through the
above phases, gradually adding new features and improvements. With each
iteration, the software becomes more robust and feature-rich.

The key advantage of the incremental model is its ability to provide early and
continuous releases of usable software, which can help gather user feedback
and adapt to changing requirements.

Advantages

●​ Early Release of Partial Functionality: Incremental model allows for the early
release of a basic working version of the software, even if not all features are
complete. This can be advantageous for getting user feedback and satisfying
immediate needs.
●​ Reduced Risk of Big Failures: Since the development process is broken down
into smaller, manageable chunks, the risk of a catastrophic failure is reduced. If a
problem arises, it is typically easier to identify and address in a smaller
increment.
●​ Feedback Incorporation: Each increment can be reviewed by stakeholders and
users, leading to the incorporation of their feedback into subsequent increments.
This ensures that the final product better aligns with user expectations.
 ●​ Flexible and Adaptive: Changes and adjustments can be accommodated more
easily during the development process. The incremental model allows for
flexibility in adapting to changing requirements.
●​ Early Availability of Features: Core features can be delivered early, allowing
users to start benefiting from the software sooner, even if the complete
application is still being developed.
●​ Reduced Development Time: By breaking down the project into smaller
increments, development time can be reduced as the focus is on delivering a
subset of features in each iteration.

Disadvantages

●​ Complexity in Integration: Integrating new increments with existing components

can be challenging, especially if the architecture wasn't designed with
incremental development in mind. This can lead to compatibility and stability
issues.
●​ Continuous Maintenance Overhead: As increments are added, maintaining and
updating them can become complex, leading to increased maintenance
overhead over the lifecycle of the software.
●​ Limited Overall View: Since the software is developed incrementally, there might
not be a comprehensive overview of the final product until all increments are
integrated, potentially leading to discrepancies in overall design and functionality.
●​ Incomplete Features: Depending on the chosen increments, some critical
features might not be available until later stages of development, which could
hinder the usability of the software during early releases.
●​ Dependency Management: If one increment relies on the functionality of another,
delays in one increment can impact the overall project timeline and deliverables.
●​ Increased Coordination Effort: Managing the development and integration of
multiple increments requires effective coordination and communication among
development teams, which can become complex as the project progresses.
●​ Limited Applicability: The incremental model might not be suitable for all types of
projects, especially those with strict regulatory requirements or those that require

a complete and cohesive system from the start.

 3.Evolutionary Model:

Evolutionary Model is a combination of iterative and incremental model of

software development life cycle.

In simple words,

“Iterative” + “Incremental model” = Evolutionary model.

●​ Iterative waterfall model can be thought of as

incorporating the necessary changes to the
classical waterfall model to make it usable in
practical software development projects.
●​ The iterative waterfall model provides feedback
paths from every phase to its preceding phases,
which is the main difference from the classical
waterfall model.
It is better for software products that have their feature sets redefined during
development because of user feedback and other factors.

The Evolutionary model divides the development cycle into smaller,

incremental waterfall models in which users are able to get access to the
product at the end of each cycle.

Feedback is provided by the users on the product for the planning stage of the
next cycle and the development team responds, often by changing the
product, plan or process. Therefore, the software product evolves with time.

4.The Unified Models

The framework is also known as

 ●​ Rational Unified Process (RUP) and

●​ Open Unified Process (Open UP).

This is an iterative and incremental software development approach that

utilizes the Unified Modeling Language (UML) for design and documentation,
essentially combining best practices from different methodologies into a
single, structured framework.

The Unified Process (UP) is a software development framework used for

object-oriented modeling. Some of the key features of this process include:

Key features

●​ It defines the order of phases.

 ●​ It is component-based, meaning a software system is built as a set of

software components. There must be well-defined interfaces between

the components for smooth communication.

●​ It follows an

❖​use-case driven approach,

❖​iterative,

❖​incremental,

❖​architecture-centric, and

The use case-driven approach

Use a case-driven approach that follows a set of actions performed by one or

more entities. A use case refers to the process of the team performing the

development work from the functional requirements. The functional

requirements are made from the list of requirements that were specified by

the client. For example, an online learning management system can be

specified in terms of use cases such as "add a course," "delete a course," "pay

fees," and so on.

The architecture-centric approach

The architecture-centric approach defines the form of the system and how it

should be structured to provide a specific functionality whereas the use case

defines the functionality.

The iterative and incremental approach

An iterative and incremental approach means that the product will be

developed in multiple phases. During these phases, the developers evaluate

and test.

Phases

We can represent a unified process model as a series of cycles. Each cycle

ends with the release of a new system version for the customers. We have

four phases in every cycle:

●​ Inception

●​ Elaboration

●​ Construction

●​ Transition

1.Inception
The main goal of this phase involves delimiting the project scope. This is

where we define why we are making this product in the first place. It should

have the following:

●​ What are the key features?

●​ How does this benefit the customers?

●​ Which methodology will we follow?

●​ What are the risks involved in executing the project?

●​ Schedule and cost estimates.

2.Elaboration

We build the system given the requirements, cost, and time constraints and all

the risks involved. It should include the following:

●​ Develop with the majority of the functional requirements implemented.

●​ Finalize the methodology to be used.

●​ Deal with the significant risks involved.

3.Construction

This phase is where the development, integration, and testing take place. We

build the complete architecture in this phase and hand the final

documentation to the client.

4.Transition
This phase involves the deployment, multiple iterations, beta releases, and

improvements of the software. The users will test the software, which may

raise potential issues. The development team will then fix those errors.

Personal Software Process (PSP):

The Personal Software Process (PSP) emphasizes personal measurement

and quality of work products, making individuals responsible for planning,
estimating, and controlling quality.

Activities

Personal software process defines 5 framework activities

Cons

It is not widely accepted bcoz,

Team Software Process (TSP)

The Team Software Process (TSP) aims to build self-directed teams that plan,

track work, establish goals, and manage their own processes and plans.

The team itself creates its own process and at the same time meet the narrow
needs of individuals and the broader needs of the organisation

The goal is to build a “self detected” project team that organizes itself to produce

high quality software.

 ●​ Build self directed teams that plan and track their work established goals
and own their processes and plans. These can be pure software teams or
integrated product teams consisting of three to 20 engineers.
●​ Show managers how to coach and motivate their teams and how to help them
sustain peak performance
●​ Accelerate software process improvement by making CMM level 5 behaviour
normal and expected (Capability maturity model) CMM, a measure of the
effectiveness of a software process which we had discussed before)
●​ Provide improvement guidance to high maturity organisations

Note: While PSP focuses on the individual, TSP focuses on building

high-performing teams of 3-20 engineers to accelerate process improvement.

Agile software development

Agile software development methodologies are one of the simplest and most effective
processes for translating a vision for a business need into a software solution. Agile is a
term used to describe software development approaches that include continuous
planning, learning, improvement, team collaboration, evolutionary development, and
early deployment. Promote flexible responses to change.

Agile SDLC model is a combination of iterative and incremental process

models with focus on customer satisfaction by rapid delivery of working

software products.

Agile Methods break the product into small incremental builds. These builds

are provided in iterations. Each iteration / sprint typically lasts from

about one to 2 weeks. Every iteration involves cross functional teams

working simultaneously on various areas like −

Phases of agile methodology

The different Phases of project development are:

●​ Planning
●​ Design
●​ Development/Implementation
●​ Testing
●​ Deploy
●​ Reviews from customer

After taking the feedback from the customer, these phases are implemented again, and
then again, the feedback is taken from the customer, and the phases are repeated. This
happens until the customer is satisfied or accepts the final project.
 ●​ The agile development process usually deploys Pair Programming.
In Pair programming, two programmers work together at one
workstation. One does coding while the other reviews the code as it
is typed in. The two programmers switch their roles every hour or
so.

Agile Manifesto principles

​ Individuals and interactions − In Agile development,

self-organization and motivation are important, as are interactions like

co-location and pair programming.

​ Working software − Demo working software is considered the best

means of communication with the customers to understand their

requirements, instead of just depending on documentation.

​ Customer collaboration − As the requirements cannot be gathered

completely in the beginning of the project due to various factors,

continuous customer interaction is very important to get proper

product requirements.

​ Responding to change − Agile Development is focused on quick

responses to change and continuous development.
Agile is an umbrella term for a set of methods and practices based on the
values and principles expressed in the Agile Manifesto

Organizations can be agile using many of the available frameworks

available such as Scrum, Kanban, Lean, Extreme Programming (XP) and
etc.

The primary goal of being Agile is to empower the development

team with the ability to create and respond to change in order to

succeed in an uncertain and turbulent environment.

Advantages of Agile model

1. Efficiency

By using multiple approaches simultaneously, you save time and resources. Plus, this
model is more effective in overcoming resistance to changes. Since each change
occurs in different projects simultaneously, implementing new ideas is much easier than
with a single project approach.

2. Adaptability

This model is configured to respond to changing situations quickly and effectively. In

contrast, long-term planning approaches require additional adapt lead times since it’s
done after the plans are made.

3. Quick

If a new system needs to be built for an upcoming event, an agile team can quickly
respond with minimal planning time. They can quickly adapt by changing code or adding
new features to suit the occasion. In contrast, long-term planning approaches require
additional adapt lead times since it’s done after the plans are made.

4. Stakeholders have an idea about the project’s progress and work.

After each iteration, project customers and stakeholders have a complete picture of the
updated software developed according to an agile model. In this way, all changes in the
system can be addressed in each iteration.

Disadvantages of agile model

1. Limited documentation

In Agile, documentation happens throughout the project, often in time to create the
output rather than at the beginning. This leaves less detail and is often delayed. Due to
the absence of proper documentation, when the project completes and the developers
are assigned to another project, maintenance of the developed project can become a
problem.

2. High quality customer interactions

The agile model depends highly on customer interactions so if the customer

is not clear, then the development team can be driven in the wrong direction.

3. Demands strong expertise from team members

Agile development models require a high degree of expertise from team

members, as they need to be able to adapt to changing requirements and

work in an iterative environment. This can be challenging for teams that are

not experienced in agile development practices and can lead to delays and

difficulties in the project.

Difference between waterfall model and agile model

 Waterfall Model Agile Model

Requirement The method is ideal for Requirements are expected to

projects which have definite change and evolve in the agile
requirements and changes model.
not at all expected.
 Feedback There is no feedback system There is a continuous feedback
by customer system by customers.

Controlling In the waterfall method, the The Agile Team contributors are
supervisor procedure is continually interchangeable; as a result, they
trustworthy, so the venture paint faster. Likewise, no want for
supervisor performs a crucial venture managers because the tasks
position throughout each are controlled through the complete
degree of SDLC. team.

Testing In this methodology, the In Agile methodology, testing is

“test” phase comes after the performed concurrently with software
“build” phase. development.

Some of the agile models:

Scrum
SAFe

What is the difference between SAFe Agile and Agile?

Agile is the ideal methodology for working with smaller teams; SAFe, on the other hand,
can help keep processes simple while ensuring quality for working with larger teams.

Scrum is a lightweight Agile framework for small teams, while Scaled Agile Framework
(SAFe) is a more comprehensive framework for large organizations. Both are widely
used Agile frameworks.
SAFe

The Scaled Agile Framework (SAFe) is a set of organizational and workflow patterns for
implementing agile practices at an enterprise scale. The framework is a body of
knowledge that includes structured guidance on roles and responsibilities, how to plan
and manage the work, and values to uphold.

SAFe promotes alignment, collaboration, and delivery across large numbers of agile
teams. It was formed around three primary bodies of knowledge: agile software
development, lean product development, and systems thinking.

As businesses grow in size, SAFe provides a structured approach for scaling agile.
There are four configurations in SAFe to accommodate various levels of scale:
●​ Essential SAFe,
●​ Large Solution SAFe,
●​ Portfolio SAFe, and
●​ Full SAFe.

How does SAFe Work?

Scaled Agile, Inc. provides a SAFe implementation roadmap that contains detailed steps
on how to get started and set up the organization for widespread adoption across
portfolios. The 12 steps for implementing SAFe include:

➢​ Reaching the tipping point

➢​ Train lean-agile change agents
➢​ Train executives, managers, and leaders
➢​ Create a lean-agile center of excellence
➢​ Identify value streams and ARTs (Agile Release Trains)
➢​ Create the implementation plan
➢​ Prepare for ART launch
➢​ Train teams and launch the ART
➢​ Coach the ART execution
➢​ Launch more ARTs and value streams
 ➢​ Extend to the portfolio
➢​ Sustain and improve

The best software process model depends on the project requirements, team,
and other factors. For highly flexible and iterative development, Agile is often
preferred for its adaptability and frequent feedback loops. The Waterfall model
can be effective for well-defined projects with clear requirements due to its
structured approach.
Communication Principles in Software Engineering

There are some principles outlined for effective communication for the ideal development of the
end product.

Deploy
Communic Planning Mode Constructi
ment
ation lling on

Communication principles
1) Listen carefully: –​ To understand customers' requirements perfectly and listen carefully to
speakers which ensure proper data collection. Ask for classification of something is under , but
avoid constant interceptions. Concentrate on speakers’ words so there should be any chance of
misinterpretation.

2) Prepare before you communicate: – spend the time to understand the problem before meeting
with customers. If necessary, do some research to understand business terminologies .So it is
necessary to prepare the agenda for the meeting.
3) Someone should facilitate the activity: – every communication meeting should have a leader
to keep conversation moving in productive direction. To solve any conflict that does occur

4) Face-to-face communication is best: – face-to-face communication is better but even if some

document related to that particular subject or discussion is given. The drawing and documents
speak better.

5) Take notes and document decisions: – note down all important points and issues raised in the
meeting and maintain record. One participant of the meeting may act as a recorder for the notes
and document decision.

6) Strive for collaboration: – collaboration in team members is essential for better team work.
Collaboration is achieved when collective knowledge of member of the team is united to
illustrate product of system function or system feature. It helps to build faith among team
member and create generic goal for team. So the collaboration is very important in the team
members.

7) Stay focused, modularize your discussion :- the more people involved in any communication
the more chances to bounce topic form one to other. The facilitator should keep conversation in
one direction and important topic will be focused. so stay be focused modularize with your
discussion.

8) If something is unclear, draw a picture :- though verbal communication is important a sketch

or drawing can be often provide clarity when words fails to do job so that’s why draw the clear
drawing or picture for particular stage.

9) Keep the discussion to “ move on ” :-

a) once there is an agreement to do something.

b) If you cannot agree to something.

C) If a feature of function is not clear. In the meeting many people require to discussion different
issues. So communication like any software engineering activity takes time .the people who
participate should recognize many topics require discussion and that “ moving on ” is best
option to achieve communication.

10) Negotiation is successful when both parties win :- there are many instances in which
software engineer and customer must negotiate function and feature priorities and delivery dates.

Planning Principles

The project planning process involves a set of interrelated activities followed in an orderly
manner to implement user requirements in software and includes the description of a series of
project planning activities and individual(s) responsible for performing these activities. In
addition, the project planning process comprises the following.

●​ Objectives and scope of the project

●​ Techniques used to perform project planning
●​ Effort (in time) of individuals involved in project
●​ Project schedule and milestones
●​ Resources required for the project
●​ Risks associated with the project.

Project planning process comprises several activities, which are essential for carrying out a
project systematically. These activities refer to the series of tasks performed over a period of time
for developing the software. These activities include estimation of time, effort, and resources
required and risks associated with the project.
Fig: Project Management perceptive

Approaches
Minimum consider the strategies needed at minimum to start.
Traditional very methodical approach touching every aspect of the turns of the project.
Agile way Be quick and keep reviewing the adopted strategies every moment.

Principles
1.​ Understand the scope of the project. Scope → amount of the effort
2.​ Involve stakeholders in plan process. StakeHolder → The persons who impacts
3.​ Recognize that the plan is iterative. As work starts things change. Adjust changes.
4.​ Estimate based on what you know plan. Every point, estimate.
project management triangle or the iron triangle, is a model that
shows how scope, time, and budget relate to each other.

5.​ Consider the risk as you define the plan. Contingencies and risk mitigation
6.​ Be Realistic. Don’t be ignorant of real happenings. Tech expert leaves. Govt rules chges…
7.​ Adjust granularity as you define plan
8.​ Define how you intend to ensure quality
9.​ Define how you intend to accommodate the change
10.​Keep track the frequently and make adjustments as required
Modelling Principles

When a physical thing is being built we create or model in an identical form

but shape is smaller in scale.
When the software is built our model must be capable of representing the
information that software transforms; s/w Architecture and functions;
features behaviour of the system as transformation is taking place.
In software engineering, 2 different models can be created:
1)​ Requirement model and 2) Design model

Requirement models
represent customer requirements by the covering software in 3 different
domains, 1) information 2) functional and 3) behaviour

Design models
help people to construct effectively the Architecture, the UI user’s interface
the component levels

We should know P O C
Principles

1.​ The primary goal of the software team is to build software, not create models
2.​ Travel lite – don't create more models than needed
3.​ Strive to produce the simplest model that will describe the problem or the software
4.​ Build the models in a way that makes them responsive to change
Assume that the models will change.
Without a good requirements model if you create a design model, it will miss
important features of the product.
5.​ 5Be able to state an explicit purpose for each model that is created
6.​ Adapt the models you develop to the system at hand
Ex. Enterprise app vs Gaming app
7.​ Try to build useful models but forget about building perfect models
8.​ Don't become dogmatic about the syntax of the model you could communicates and
content successfully representation is secondary
SO think of UML
9.​ If you were finishing tell you a model isn't right even though it seem so can paper you
proudly have a reason to be concerned
10.​Get feedback as soon as you can
You have take other stakeholders inputs for clarity
Construction Principles

This is the phase where the actual coding is worked on based on the previous inputs.

Coding activity:
program from scratch
Use tools to create a place holders from architecture diagrams

[Never copy code from proprietary public sites / applications]

Testing activity:
Integration Testing: Integrates all of the components and test
Validation Testing: test if all of the requirements are met for entire application
Acceptance testing: test different scenarios if the user test for all of the features
and functions
Coding phase practices:
Understand the problem
Identify the programming lang; tools like IDE Environment
Identify the tools and helper apps
Every line of code should be carefully evaluated
Follow indentation practices
Be judgemental for naming variable names, method names
For each of the methods / functions write junit tests
Make modularization; never write monolithic code.

follow good coding practices like, cohesion, Loose coupling, Design patterns etc.
Do pair programming if adheres to the organization practices.
Conduct code reviews

Principles

Deployment Model

Software deployment is the process of making software available for use on a

system. It involves installing, configuring, and updating software.
Principles
Requirements Engineering

●​

●​

●​

Different tasks are there comprising Reqts Engg:

Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
(Requirements)Management
Inception

This is the initiation part of the project.

This tells how the project get started.
The feasibility study / market research has to be performed.
StakeHolders should present: Business Managers, Marketing staff,
Technology dept hierarchy, software team etc.
Then identify a working description of the project’s scope.
A basic understanding of the problem is established. Then try to provide or
find out the solution with preliminary communication and collaboration with
the stakeholders and s//w team.

Ex. Ola, Uber, Swiggy. → how they started and became the successful
Elicitation

An important part of this task is to settle down with business goals.

Engage the stakeholders and make sure they participate honestly in the
sharing of the thoughts towards keep refining the goals more and more.
Then the potential architecture can be created.
Christel and Kang identified the 3 problems in Elicitation:
​ 1.Problems of Scope
2.Problems of understanding

3.Problems of volatility

Elaboration

The inputs of elaboration are : 1. Inception and 2. Elicitation.

These 2 are expanded and refined during the Elaboration
Elaboration is driven by the creation and refinement of user scenarios
describing how the end user and other actors as well will interact the
system
Each user scenario is a parsed to extract analysis classes

Negotiation
Customers ask for conflicting requirements
Reconcile those conflicts through a process of negotiations
Discuss with customers to prioritize the reqts and provide the ranks
Now, assess the cost and risks with the changed or negotiated
requirements and address any conflicts

Validation
Systems Engineering
Business Process Engineering

Product Engineering
Types of S/w Products
Essential characteristics of well engineered S/w product
Roles and responsibilities