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 followups,
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.

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.

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.

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.